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TEST  AND  EVALUATION  YEAR-2000  TEAM  REPORT 

to  the 

Test  and  Evaluation  Board  of  Operating  Directors 
July  10, 1996 

EXECUTIVE  SUMMARY:  The  Test  and  Evaluation  (T&E)  Board  of  Operating  Directors 
(BoOD)  commissioned  a  T&E  Year-2000  Team  in  March  1996  to  assess  the  vulnerability  of  the 
T&E  community  to  Year  2000  problems  and  their  impact  within  the  Department  of  Defense 
(DoD)  T&E  community.  These  problems  are  those  which  will  affect  computer  based  systems  at 
or  near  the  transition  to  the  year  2000.  These  problems  can  lead  to  possible  year 
misrepresentation  internal  to  computers,  their  associated  programs  and  their  related  data  stores. 
The  T&E  Year-2000  Team  focused  on  case  studies  within  the  Major  Range  and  Test  Facility 
Base  (MRTFB)  to  extrapolate  an  assessment  of  the  overall  Year  2000  issue  as  it  pertains  to  T&E. 
The  team  also  surveyed  parallel  DoD  efforts  and  commercial  support  available  to  resolve  Year 
2000  issues.  The  team  discovered  that  the  T&E  community  was  vulnerable  in  subtle  ways  to  the 
Year  2000  issue.  We  learned  that  many  major  scientific  and  engineering  computer  applications 
were  exempt  by  merit  of  the  state  of  the  art  environment  in  which  they  run  or  the  nature  of  the 
applications  themselves.  While  many  of  these  primary  applications  may  well  be  Year  2000 
compliant,  the  related  subsystems,  utilities,  feeders  and  management  systems  upon  which  they 
depend  are  not.  Thus,  where  they  exist,  Year  2000  problems  in  the  T&E  community  are  deep 
seated,  rooted  in  subtle  interfaces  and  not  patently  evident.  Prevailing  commercial  practices 
recommend  an  end-to-end  review  of  all  existing  code  for  potential  Year  2000  problems.  Often, 
however,  the  necessary  code  parsing  tools  are  unavailable  or,  when  available,  require  costly 
expertise  to  run.  Moreover,  the  original  source  code  may  no  longer  be  available  in  many 
significant  cases.  For  these  reasons,  the  T&E  Year-2000  Team  recommends  a  methodology 
whereby  the  actual  data  artifacts  from  T&E  systems  be  analyzed  for  instances  of  Year  2000 
problems  when  the  actual  code  is  unavailable.  This  can  be  most  economically  accomplished  by  a 
central  T&E  “Year-2000  Clearing  House”  which  would  impartially  screen  data  submitted  by 
T&E  installations.  The  resulting  annotated  data  maps  and/or  code  reviews  would  then  be  shared 
with  the  affected  installations  for  Year  2000  problem  prioritization  and  repair.  A  significant  side 
benefit  is  that  data  maps,  when  created,  also  serve  as  substantive  analytical  tools  for  broader 
enterprise  re-engineering  initiatives.  Once  the  high  priority  code  is  corrected  at  the  installation 
level,  subsequent  testing  would  be  performed  by  the  T&E  “Year-2000  Clearing  House”.  This 
approach  minimizes  the  number  of  knowledgeable  tool  practitioners  and  reduces  the  overall  cost 
and  effort  necessitated  by  data  analysis  and  code  parsing  at  the  local  level.  Moreover,  as  the  T&E 
“Year-2000  Clearing  House”  gains  proficiency,  it  can  offer  its  services  to  other  DoD  elements 
and  thus,  potentially  reimburse  or  exceed  the  initial  investment  necessary  to  get  it  operationally 
proficient.  The  team  also  strongly  recommends  a  program  urgently  aimed  at  heightened 
awareness  of  the  importance  of  this  problem. 
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TEST  AND  EVALUATION  YEAR-2000  TEAM  REPORT 

to  the 

Test  and  Evaluation  Board  of  Operating  Directors 
July  10, 1996 

SECTION  1:  POTENTIAL  YEAR  2000  PROBLEMS:  There  is  a  real  risk  that  automated 
systems,  including  software  applications,  will  yield  inaccurate  results  at  or  near  the  century 
change.  This  problem  manifests  itself  when  the  year  becomes  2000,  and,  in  some  special  cases, 
1999.  For  example,  the  Global  Positioning  System  (GPS)  has  a  date  related  error  in  its  receiver 
technology  which,  if  not  corrected  in  all  GPS  receivers,  will  invalidate  GPS  positioning  data 
after  August  1999.  Business  systems,  heavily  dependent  on  dates  to  control  their  processing,  if 
not  fully  corrected  for  Year  2000  faults,  could  create  massive  disruptions  in  fundamental 
business  areas  upon  which  T&E  depends.  Functions  such  as  payroll,  accounts  payable,  accounts 
receivable,  human  resources  management  and  procurement  could  be  seriously  affected. 
Additionally,  T&E  support  systems  such  as  scheduling  tools,  maintenance  tracking  systems  and 
base  operations  support  systems  are  vulnerable  to  Year  2000  deficiencies.  The  T&E  community 
itself  may  be  vulnerable  to  unforeseen  disruptions  in  scheduling  operations  such  as  real-time 
weapon  system  testing,  range  and  flight  safety  systems,  and  time  critical  data  processing.  For 
example,  simple  year  related  failures  in  older  T&E  data  systems  could  interrupt  operations  or 
even  affect  availability  of  primary  test  capabilities,  automated  target  tracking  systems,  telemetry 
systems,  T&E  based  computational  systems  and  vendor  provided  technical  software.  Such 
failures  could  also  lead  to  the  disruption  of  data  archival  systems  related  to  the  storage  of  T&E 
data. 

The  full  extent  of  the  potential  Year  2000  problem  is  non-trivial.  Put  into  DoD-wide  perspective, 
the  repair  effort  appears  overwhelming.  The  overall  project  in  the  DoD  community  requires  an 
incredible  level  of  coordination  and  tracking  to  ensure  success.  The  technical  issues  to  both 
business  and  scientific  computing  are  important,  but  small  in  contrast  to  the  project  management 
issues.  At  the  detail  level,  conversion  activities  (hardware,  software,  and  firmware)  are  routine 
and  definable.  They  make  up  the  greatest  portion  of  the  effort;  however,  once  defined,  assigned, 
prioritized,  and  managed  they  can  proceed  simply  and  effectively.  Contrary  to  initial 
perceptions,  century  compliance  is  primarily  an  exercise  in  large-scale  project  management. 

The  Assistant  Secretary  of  Defense  for  Command,  Control,  Communications  and  Intelligence 
(ASD(C3I))  has  formally  notified  all  of  the  Department  of  Defense  (DoD)  of  the  impending  and 
very  real  danger.  As  noted,  the  full  range  of  business  and  base  support  systems  are  in  real 
jeopardy  of  malfunctioning  at  or  before  the  year  2000.  The  size  of  the  T&E  systems’  Year  2000 
problem  appears  somewhat  more  scalable,  although  the  full  extent  of  the  situation  is  not  yet 
defined.  Accordingly,  the  Director  for  Test,  Systems  Engineering  and  Evaluation  (DTSE&E)  in 
the  DoD  Office  of  the  Secretary  of  Defense  (OSD)  directed  an  assessment  of  the  Year  2000 
problem  as  it  affects  T&E.  Responsively,  the  Joint  Program  Office  for  T&E  (JPO(T&E)) 
proposed  and  the  T&E  Board  of  Operating  Directors  (BoOD)  commissioned  a  T&E  Year-2000 
Team  to  undertake  an  assessment  of  the  problem  in  the  T&E  community.  Pertinent 
correspondence  and  the  text  of  the  proposal  for  a  90  day  study  effort  may  be  found  at  Appendix 
A.  The  study  methodology  adopted  by  the  team  is  at  Appendix  B. 
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A.  VULNERABILITIES:  The  “Year-2000  Problem”  is  actually  a  combination  of  several 
component  vulnerabilities  related  to  transition  to  the  year  2000. 

1.  TWO  CHARACTER  YEAR  REPRESENTATION:  The  largest  and  best  known  class  of 
“Year-2000  Problems”  involves  the  use  of  two  digit  fields  to  represent  the  year.  In  less 
technically  sophisticated  times  when  computer  storage  was  at  a  premium,  such  two  byte  year 
representation  was  a  common  convention  to  conserve  space.  The  characterization  of  this 
phenomena  appears  when  two  numeric  or  alphabetic  characters  are  used  as  a  variable  data 
element  to  represent  the  year  only  to  the  decade  level.  In  these  cases,  the  century  is  assumed  to 
be  a  “19”.  In  some  cases,  the  “19”  may  actually  have  been  hard  coded.  Often,  the  two  digit  year 
characters  are  embedded  in  a  larger  date  field.  For  example,  a  representation  of  MM/DD/YY 
places  the  two  character  year  at  the  end  of  the  larger  date  string.  In  other  cases,  such  embedded 
dates  are  more  subtle.  Examples  where  strings  of  data  may  impart  year  intelligence  include 
contract  numbers,  invoice  record  numbers  or  Job  Order  Number  (JON)  where  the  year  is 
embedded  as  a  two  character  portion  of  the  larger  number.  In  all  these  cases,  the  assumption  that 
the  century  is  “19”  will  convey  into  the  year  2000,  resulting  in  incorrect  date  and  day  of  the 
week  representation  in  all  resulting  instances  of  date  information  beyond  the  transition. 

2.  RESERVED  CHARACTERS  IN  YEAR  FIELDS:  A  related  problem  involves  the  use  of  the 
characters  “99”  and  “00”  in  year  fields.  Often  these  numbers  are  reserved  in  year  fields  to  denote 
special  conditions  that  affect  the  computer  program  operating  on  this  field.  For  example,  the  date 
string  9/9/99  is  often  assigned  by  convention  to  mean  “unlimited”  or  “unconstrained”  date  data 
is  to  be  used.  The  string  of  “99”  in  the  year  field  may  also  indicate  such  things  as  default  values, 
the  last  record  in  a  series  of  input  records  or  a  “null”  value.  In  such  cases  system  “rollovers”  on 
January  1,  1999  can  trigger  specific  misrepresentations  of  year  data  to  occur  a  full  year  ahead  of 
the  year  2000.  Likewise,  use  of  “00”  in  the  year  field  may  indicate  a  null  record  or  denote  an 
interrupt  vector.  In  such  cases,  many  applications  run  in  1999  will  be  against  transactions  for  the 
year  2000.  In  both  instances  any  system  which  forecasts  transactions  by  date  are  in  jeopardy. 

3.  DATE-IN-KEY:  Another  issue  involves  data  input.  The  “date-in-key”  problem  involves  the 
use  of  interactive  screens  to  capture  date  information.  Even  if  the  year  is  internally  represented  as 
four  digit  century  data,  the  on-line  capture  field  may  use  the  two  digit  representation  to  conserve 
valuable  screen  “real-estate”.  In  such  cases,  programmatic  resolution  will  be  required  to  reconcile 
the  century  level  year  differentiation.  The  software  language  vendor  should  be  contacted  to 
ascertain  a  solution  to  this  problem. 

4.  LEAP  YEAR  CALIBRATION:  The  Leap  year  issue  is  even  more  subtle.  A  specific  year  is  a 
leap  year  if  it  is  evenly  divisible  by  400  OR  evenly  divisible  by  4  and  not  evenly  divisible  by 
100.  Thus,  the  year  1900  was  not  a  leap  year  but  the  year  2000  is.  Some  potential  exposures 
caused  by  the  identification  of  the  year  2000  as  a  non-leap  year  are: 

-  day-in-year  calculations.  The  year  2000  has  366  days;  not  365. 
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-  day-of-the-week  calculations.  February  28,  2000  is  a  Monday  and  1  March  is  a  Wednesday, 
not  a  Tuesday  which  is  February  29, 2000. 

-  week-of-the-year  calculations.  The  1 1th  week  of  the  year  2000  is  5  through  1 1  March,  not  6 
through  12  March. 

If  the  programs  that  manipulate  date  information  are  not  properly  calibrated  for  this  special  once 
every  400  year  case,  date  representation  will  be  amiss  after  the  leap  year  is  in  effect. 

5.  DAY  CLOCK:  The  “Day-Clock  Problem”  involves  an  even  deeper  abstraction.  Some 
operating  systems  (software)  are  built  such  that  the  default  date  will  revert  to  something  other 
than  the  actual  date  when  the  century  rolls  to  2000.  In  such  cases,  depending  on  the  operating 
system,  dates  may  or  may  not  be  represented  correctly,  but  file  storage  schemes  will  be 
inaccurate.  Most  existing  DOS  BIOS  implementations  (hardware)  also  have  such  problems. 

Thus,  many  personal  computers  (PC)  have  design  susceptibility  to  this  fault.  Their  Real  Time 
Clock  (RTC)  chips  (a  hardware  component)  keep  dates  as  “century/two-digit  year/month/day” 
but  their  DOS  (operating  system  -  a  software  component)  date  is  kept  as  “days-since- 
1980/01/01”.  On  January  1, 2000  the  RTC  will  roll  99  (two  digit  year)  to  00  but  the  century 
remains  at  19,  so,  we  have  19/00/01/01  and  the  date  01,01,2000  effectively  becomes  01,01,1900. 
Seemingly,  DOS  correctly  handles  the  change  making  any  date  APPEAR  correct  to  the  computer 
user.  The  result,  however,  is  an  internal  date  conflict  which  the  computer  date  conversion 
algorithm  attempts  to  resolve  by  calculating  an  erroneous  date  such  as  1980-01-04  or  01/01/:0. 
Users  will  be  unaware  of  the  problem  until  they  reboot  and  attempt  to  access  a  file  with  the 
erroneous  storage/creation  date.  Over  time,  all  files  created  after  the  century  roll  over  will  have 
that  same  erroneous  creation  date.  Access  to  the  “real”  file  may  not  be  available  or  out  of 
sequence.  Other  instances  of  this  problem  could  have  devastating  results  on  archival  or  backup 
data  labeling.  (  Note  that  many  PCs  manufactured  since  mid- 1995  are  Year  2000  compliant  and 
others  contain  a  programmable  BIOS  chip  that  can  be  upgraded  by  diskette). 

6.  LICENSE  EXPIRATION:  Most  insidiously,  commercial  software  offerings  containing  an 
embedded  license  expiration  date  may  go  dead  at  the  year  2000  rollover.  Worse,  if  the  license 
code  is  definitive,  affected  commercial  software  will  be  “turned-off ’  permanently  when  it  “sees” 
a  year  of  “00”.  This  could  happen  even  when  only  experimenting  to  see  if  the  Year  2000  problem 
exists  within  other  components  of  the  computer  system. 

B.  IMPACTS:  These  vulnerabilities  are  compounded  by  a  number  of  practical  considerations. 

1.  EXTENT  OF  THE  PROBLEM:  The  Year  2000  problem  is  pervasive  and  has  a  well  known 
deadline.  It  particularly  extends  to  aged  legacy  systems.  In  such  cases,  the  source  code  that 
produces  the  undesirable  Year  2000  results  may  well  be  unavailable,  unreadable,  impossible  to 
recompile,  undocumented  or  legally  inaccessible  because  of  contractual  “ownership”  issues.  In 
other  cases,  Year  2000  compliant  systems  are  negatively  affected  by  input  data  from  other  non- 
compliant  systems.  In  fact,  studies  reveal  the  majority  of  Year  2000  problems  will  manifest 
themselves  at  the  interface  level.  Often  this  problem  is  aggravated  by  less  obviously  involved 
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embedded  software  in  systems  and  subsystems.  The  rapid  growth  of  electronic  communications 
systems  also  tend  to  propagate  and  worsen  this  potentially  serious  phenomena. 

2.  HIDDEN  NATURE  OF  THE  PROBLEM:  The  manipulation  of  date  information  can  often  be 
hard  to  discover.  Date  manipulations  may  span  hundreds  of  lines  of  code  within  a  given 
application.  In  some  instances,  these  manipulations  can  occur  across  related  programs  or  within 
or  among  supporting  utilities.  Often,  year  manipulations  are  embedded  in  controllers,  firmware 
based  micro-code,  operating  systems,  real-time  clocks  and  other  less  than  obvious  system  level 
resources.  Thus,  even  if  the  application  has  no  apparent  date  manipulation  algorithms,  it  still  may 
not  be  exempt  from  one  of  the  Year  2000  related  problems.  A  simple  example  of  this  phenomena 
is  a  subroutine  that  date  stamps  the  header  information  in  archival  tapes  regardless  of  the  rest  of 
the  content. 

3.  TESTING  THE  PROBLEM:  Testing  for  Year  2000  compliance  yields  other  problems.  Even  if 
a  single  application  is  compliant,  its  testing  must  be  synchronized  with  companion  applications 
which  may  pass  date  information  to  assure  the  overall  system  of  applications  is  safe  to  run.  This 
problem  is  non-trivial.  Worse,  large  production  systems  cannot  be  shut  down  for  testing.  Even 
where  possible,  testing  with  the  year  2000  change  can  create  unexpected  havoc  among  existing 
production  data.  In  most  cases,  setting  up  a  parallel  system  for  tests  is  utterly  prohibitive  by  cost 
or  practical  considerations. 
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SECTION  2:  T&E  YEAR-2000  TEAM  FINDINGS:  The  following  section  details  T&E  Year- 
2000  Team  findings  from  the  initial  case  study  approach: 

A.  INTERVIEW  RESULTS:  The  specific  results  of  the  focused  team  interviews  may  be  found  at 
Appendix  C.  The  Year  2000  problem  is  not  trivial  within  T&E,  but  may  not  be  as  widespread  as 
initially  feared  within  primary  applications  employed  by  the  T&E  community.  The  outward 
appearances  are  that  a  large  number  of  primary  functional  applications  are  totally  exempt  from 
Year  2000  related  problems.  The  hidden  component  of  the  Year  2000  issue,  however,  still  exists 
beyond  and  beneath  the  obvious  functional  considerations  found  at  the  applications  level.  The 
Year  2000  transition  problems  definitely  affect  significant  portions  of  the  business,  scientific  and 
desktop  systems  within  the  entire  T&E  community.  The  real  issue  is  that  these  problems,  where 
they  exist,  are  insidious  and  not  self-evident  by  the  casual  observer  or  even  the  dedicated  user. 
The  interviews  indicated  that  most  managers  were  willing  to  leam  more  about  the  Year  2000 
problem  and  take  necessary  actions.  There  was,  however,  a  subtle  undercurrent  of  denial  in  the 
sense  that  the  problems  were  attributed  to  “someone  else”,  such  as  vendors  or  program  creators, 
or  that  the  problem  was  not  immediately  observable,  so  therefore  must  be  trivial. 

1.  BUSINESS  SYSTEMS:  Business  systems  are  clearly  the  most  susceptible  to  serious  Year 
2000  problems  at  MRTFB  sites.  Many  business  systems  and  corporate  information  systems  at 
the  ranges,  however,  run  under  modem  database  management  systems  (DBMS)  such  as  Oracle 
and  its  tools.  Systems  running  under  such  DBMS  are  considered  "safe"  in  so  far  that  these  tools 
force  four  place  date  fields  within  the  databases  themselves.  Most  "major"  business  systems  have 
been  or  will  soon  be  converted  in  the  Navy  and  Air  Force  sites  studied.  The  Army,  however,  still 
employs  mainframes  running  a  significant  number  of  Common  Business  Oriented  Language 
(COBOL)  programs  and  earlier  vintage  databases.  These  applications  are  highly  suspect  in  terms 
of  potentially  undesirable  Year  2000  instances.  Additionally,  all  remaining  legacy  business 
systems,  small  localized  feeder  systems,  and  unconverted  middle-ware  supporting  major  systems 
at  all  sites  are  in  the  most  jeopardy  of  creating  major  Year  2000  problems  at  the  T&E  sites.  Feeds 
from  externally  managed  Central  Design  Agent  (CDA)  systems  and  other  external  feeder 
systems  regardless  of  size  which  are  not  corrected  for  the  year  2000  pose  a  significant,  but 
presently  not  yet  fully  dimensioned,  risk  throughout  the  business  data  processing  community 
within  T&E.  As  has  been  reported  by  industrial  Year  2000  practitioners,  the  primary  Year  2000 
problems  are  at  the  interfaces  between  related  systems.  Thus,  while  primary  systems  may  well  be 
“date  safe”,  the  integrated  operations  they  support  may  well  be  highly  vulnerable  to  Year  2000 
failures. 

2.  SCIENTIFIC  SYSTEMS:  Scientific  systems  appear  by  the  testimony  of  their  managers  to  be 
less  vulnerable  to  outright  Year  2000  problems.  While  their  specific  “face-value”  Year  2000 
vulnerabilities  appear  to  be  less  widespread,  the  threats  are  far  more  subtle  in  nature  where  they 
do  exist.  Most  scientific  applications  deal  substantively  with  the  passage  of  time  and  the  precise 
measurement  of  elapsed  time  in  a  relative  sense,  but  few  involve  time  calculations  which  include 
dates  or  years.  Such  "date  free"  systems  are  exempt  from  Year  2000  problems  by  all  apparent 
functional  measures.  Some  specific  areas  of  vulnerability,  however,  appear  to  lend  themselves  to 
a  higher  probability  of  Year  2000  occurrences  within  the  T&E  scientific  computing  community. 
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Initial  reaction  among  the  T&E  engineers,  computer  scientists,  and  technicians  interviewed  was 
vague  awareness  of  the  Year  2000  issue  and  an  expression  that  it’s  impact  on  their  systems  was 
minimal  to  none.  Only  one  of  those  interviewed,  however,  had  a  complete  inventory  of  his 
division’s  computer  hardware  and  software  applications.  Most  functional  computer  applications 
in  T&E  are  primarily  concerned  with  operating  complex  scientific  instrumentation  systems 
which  gather,  analyze,  and  store  test  data.  As  noted  above,  these  systems  deal  with  data  and 
time  measurements  on  the  order  of  milliseconds  and  microseconds.  The  year  is  typically  not  a 
factor  in  these  measurements.  This  fact  caused  these  T&E  professionals  to  dismiss  the  Year 
2000  problem  as  having  no  impact  on  their  systems.  Further  discussions  with  them  about 
specific  instances  of  the  use  of  date  information  in  their  system’s  computer  software  revealed 
potential  impacts  which  they  had  not  considered.  These  potential  impacts  arose  from  the 
operating  system  supporting  their  instrumentation  system’s  application  software  and  from 
subprograms  (such  as  calibration  and  data  recording/reporting)  associated  with  the  main 
application  software.  Extensive  offline  testing  would  be  needed  to  gauge  the  true  extent  of  these 
type  of  date  problems. 

Year  2000  concerns  often  lie  embedded  in  older  hardware  and/or  firmware  in  scientific  systems 
making  them  harder  to  detect  and  potentially  insidious  as  they  tend  to  act  as  "time  bombs".  The 
Joint  Test  Assets  Database  (JTAD)  produced  a  large  list  of  Patuxent  River-based  laboratories 
each  of  which  most  likely  contain  one  or  more  computational  assets.  The  Patuxent  River 
inventory  system  identified  a  heterogeneous  list  of  computers  operating  within  the  site’s 
laboratories.  These  lists  reveal  that  many  applications  are  running  under  a  wide  variety  of 
operating  systems.  Large  scale  Time  Space  Position  Information  (TSPI)  systems  such  as  IRIG- 
based  tools  or  the  Global  Positioning  System  (GPS)  and  its  calibration  ephemera  pose  a 
potential,  but  not  as  of  yet  dimensioned,  concern.  Command,  Control  and  Communications 
systems,  including  localized  data  links  and  Systems  Under  Test  (SUT),  may  contain  latent  Year 
2000  embedded  design  susceptibilities  and  require  further  research.  Sub-systems  that  place 
labeling  and  header  information  on  storage  media  may  also  exhibit  year  related  problems  after 
year  2000. 

Tests  conducted  on  two  radar  systems  revealed  that  these  computers’  operating  systems  would 
not  accept  year  2000  dates  as  valid  and  one  would  not  “boot  up”.  If  the  radar  computer  won’t 
boot  then  the  application  software  will  not  load.  The  operating  system  in  this  case  is 
approximately  8  years  old;  however,  it  is  supported  by  the  manufacture  under  a  maintenance 
contract.  This  manufacturer  was  unaware  of  the  Year  2000  problem  but  affirmed  that  it  would 
investigate  solutions/cost  to  fix.  The  fix  could  be  as  simple  as  installation  of  the  latest  version  of 
the  operating  system.  The  isolation  and  resolution  of  similar  deficiencies  within  T&E  systems 
awaits  further  analysis  across  the  T&E  community. 

Some  instrumentation  systems  on  one  range  utilize  “star  calibration”  to  perform  system  level 
calibrations.  This  is  typically  a  subprogram  of  the  main  application  program  and  involves  input 
of  a  date  to  determine  a  reference  or  fix  of  the  star  position  in  relation  to  the  instrumentation 
system.  Testing  has  not  been  done  to  determine  Year  2000  impact.  The  instrumentation 
system’s  manufacturer  has  been  queried  but  no  new  information  arising  from  this  was  available 
at  the  time  of  this  report. 
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Much  test/calibration  equipment  that  is  used  to  maintain  these  complex  instrumentation  systems 
utilize  microprocessors  and  software  to  function.  Tests  have  shown  that  the  century  change  will 
impact  this  equipment.  While  some  of  these  computers  are  scheduled  for  replacement  before 
2000,  several  affected  systems  are  not  slated  for  replacement. 

Scientific  data  processing  is  directly  and  indirectly  dependent  on  business  systems,  planning 
systems,  scheduling  systems  and  other  “mundane"  large  to  intermediate  sized  utilities  for  smooth 
functioning  and  logistics.  To  this  extent  the  scientific  computing  community  is  vulnerable  to  and 
has  a  direct  stake  in  the  Year  2000  problem.  Feeds  from  external  systems  not  corrected  for  the 
year  2000  pose  a  potentially  substantial  risk  throughout  the  T&E  scientific  data  processing 
community  so  far  as  these  systems  contain  embedded  two  digit  date  information  which  is  or  may 
be  subsequently  used  in  further  calculations. 

3.  DESKTOP  SYSTEMS:  Many  personal  computers  (PC)  contain  embedded  Operating  System 
and  DOS  BIOS  Year  2000  related  design  faults.  These  concerns  can  range  from  complete 
devastation  to  mild  inconvenience  based  on  how  they  are  embodied  and  how  the  systems  are 
employed  by  their  users.  For  example,  the  Naval  Air  Warfare  Center  -  Patuxent  River,  Maryland 
has  some  8,000  PCs  and  700  MACs  (Macintosh  computers’  operating  systems  are  Year  2000 
compliant  and  do  not  exhibit  Year  2000  problems)  listed  on  the  Division-wide  inventory.  The 
consequence  to  localized  and  base-wide  electronic  mail  and  data  exchange  capabilities,  based 
largely  on  personal  computer  technology  are  not  yet  assessed.  There  are  no  known  additional 
funds  available  to  seek,  isolate  and  resolve  such  Year  2000  issues.  There  is,  however,  a  sense 
among  those  interviewed  that  the  rate  of  turnover  among  PCs  will  replace  presently  vulnerable 
systems  with  Year  2000  compliant  systems  within  ample  time.  Moreover,  there  is  a  known,  free 
“fix”  to  the  PC  Year  2000  problem  available  to  users  of  the  World  Wide  Web.  An  explanation 
of  the  Year  2000  problem  on  PCs,  a  compliance  test,  and  the  WEB  page  address  for  the  “fix” 
can  be  found  at  Appendix  D.  For  these  reasons,  no  costs  have  been  attributed  to  T&E  for 
correcting  Year  2000  problems  for  PCs  in  this  report.  The  onus  will  be  on  users  who  retain  their 
existing  Year  2000-flawed  computers  into  the  next  century  to  adopt  the  correction. 

B.  COST  ASSESSMENT  FOR  T&E  YEAR  2000  REMEDY:  For  the  purpose  of  discussing 
costs  associated  with  eliminating  the  Year  2000  problem  from  the  T&E  community,  computer 
assets  were  divided  into  three  broad  categories:  pure  T&E  computer  assets,  ancillary  (base 
operations,  range  scheduling,  program  management,  etc.),  and  functional  dependencies 
(information  systems  in  finance,  supply,  etc.).  The  pure  T&E  computer  assets  are  further 
subdivided  into  mainframes,  workstations,  servers  and  desktops.  As  noted  above,  no  costs  are 
reflected  in  this  report  for  desktops. 

1.  T&E  COMPUTER  ASSETS:  Testimony  from  T&E  managers  and  engineers  at  the  three  sites, 
and  the  T&E  Year-2000  Team’s  own  research  and  analysis  leads  to  the  conclusion  that  all  three 
sites  experience  almost  exactly  the  same  circumstance  regarding  Year  2000  as  an  issue. 
Generally,  the  scientific  and  engineering  applications  that  operate  on  pure  T&E  computer  assets 
were  not  found  to  be  adversely  affected  in  and  of  themselves  by  Year  2000  problems.  This  stems 
from  the  simple  fact  that  these  applications  do  not  use  dates  in  their  operation.  This  assessment 
could  not  be  verified  by  actual  physical  examination  of  representative  code  or  data,  but  was 
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affirmed  in  nearly  every  interview.  Costs  will  be  incurred,  however,  to  identify  and  replace 
hardware  and  certain  support  software  that  are  not  inherently  Year  2000  compliant  by  design.  In 
instances  where  the  hardware’s  operating  system  (OS)  is  not  Year  2000  compliant,  either  the  OS 
will  have  to  be  upgraded  or  the  hardware  replaced  (some  Original  Equipment  Manufacturers 
(OEMs)  do  not  offer  replacement  Year  2000  compliant  OSs  for  some  computer  models).  In  these 
cases,  the  engineering  applications,  while  Year  2000  compliant  themselves,  will  probably  need 
to  be  modified  to  operate  in  the  new  Year  2000  compliant  environments.  The  T&E  Year-2000 
Team  derived  the  figures  below  from  interview  statements,  inventory  lists  where  they  were 
available  and  by  gross  estimations.  In  some  cases  numbers  were  provided  only  as  rough 
approximations  and  are,  therefore,  not  considered  official 

a).  Naval  Air  Warfare  Center,  Patuxent  River:  Patuxent  River  NAS  should  be  commended  for 
their  proactive  approach  to  the  Year  2000  problem.  A  significant  program  is  underway  there  and 
detailed  data  was  available  to  assist  with  the  T&E  Year  2000  team’s  analysis.  The  following 
tables  reflect  the  number  of  pure  T&E  computing  assets  at  Patuxent  River  and  estimated  costs  to 
convert  systems  to  Year  2000  compliance. 

Patuxent  River.  MD  T&E  Computer  Assets 


Comnuter  Tvne 

Competencv  Tvne 

Number 

Total 

Mainframes/Minis 

T&E 

34 

Engineering 

25 

59 

Workstations 

T&E 

115 

Engineering 

75 

190 

Servers 

T&E 

85 

Engineering 

55 

140 

Total 

389 

Of  these  389  systems  it  can  be  assumed  that  approximately  1/3  are  or  will  be  Year  2000 
compliant  because  they  receive  normal  upgrades  from  annual  maintenance  agreements  with  the 
OEM  or  third  party  provider;  1/3  are  scheduled  for  replacement  before  2000  so  no  Year  2000 
additional  cost  will  incur,  and  1/3  (130)  must  be  upgraded.  Costs  to  upgrade  such  computers  are 
divided  into  two  categories:  systems  that  are  still  running  the  original  OS  thus  requiring  many 
layers  of  new  software  through  the  model  series  (or  complete  system  replacement  depending  on 
the  economics  and  time  constraints  of  each  situation),  and  systems  that  need  only  the  latest  OS. 
The  team  assumed  that  half  of  these  computers  will  fall  into  each  category  (65  each)  and  that 
costs  to  replace  all  the  OS-series  software  or  completely  replace  the  system  (hardware/software) 
are,  on  average,  relatively  the  same.  Attendant  application  software  modification  costs  are  also 
approximated  by  rule-of-thumb  as  equal  to  the  hardware/OS  replacement  cost. 
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1)  Total  OS  Line  or  Entire  Hardware  System  Replacement: 


65  x  $20,000  =  $  1,300,000 

2)  Latest  OS  Replacement: 

65  x  $3500  =  $  227.000 

3)  Subtotal  $  1,527,000 

4)  Application  Software  Modifications: 

$  1.527.000 

5)  Total  Patuxent  River,  MD  T&E  Costs: 

$  3,054,000 

The  FIGURE  1  Pie  Chart  below  illustrates  Year  2000  cost  distribution  for  this  T&E  Activity. 


Y2K  Cost  Estimate  for 
Sample  T&E  Activity 


Estimated  Y2K  site  cost  =  $18M 


389  T&E  systems  identified 

=>  1/3  are  “OK” 

=>  1/3  are  scheduled  for 

upgrade/replacement  before  2000 
=>1/3  must  be  fixed  (130  systems) 

•  65  require  major  effort 

Problems  typically  found  in 
hardware,  firmware,  operating 
systems,  and  interfaces 
=>  Cost  estimate  to  fix  =  $1 .5M 
Applications  generally  appear  safe 

=>  Cost  estimate  to  mitigate  impacts  of 
firmware  and  operating  system 
changes  on  applications  =  $1.5M 


FIGURE  1 
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b).  Aberdeen  Test  Center,  Aberdeen  ,  MD:  Year  2000  transition  costs  at  Aberdeen  Proving 
Grounds  for  pure  T&E  assets  are  indicated  to  be  significantly  less  than  the  Patuxent  River,  MD 
estimate.  Here  costs  for  Year  2000  range  from  $0  to  $300,000  according  to  the  information 
made  available  during  interviews. 

Aberdeen,  MD  Year  2000  Estimated  T&E  Costs: 

$  309,000 

c).  Air  Force  Flight  Test  Center  (AFFTC),  Edwards  AFB,  CA:  The  primary  engineering/range 
support  systems  located  at  the  AFFTC  have  been  either  replaced  or  upgraded  within  the  last  two 
years.  It  is  believed  that  the  hardware/software/operating  systems  currently  being  used  are 
century  aware  and  will  not  suffer  significant  problems.  Other  range  instruments  such  as  radar 
systems,  cine-theodolites,  etc.,  are  also  planned  for  upgrade,  replacement  or  to  be  mothballed 
prior  to  the  year  2000.  The  overall  feeling  was  that  the  year  2000  will  only  bring  a  minor  impact 
to  the  range/engineering  systems.  The  major  AFFTC  business  systems  that  are  expected  to 
continue  beyond  2000  are  believed  to  be  century  aware  and  also  will  not  suffer  significant 
failures.  It  is  anticipated  that  costs  for  infrastructure  and  ancillary  system  failures  may  range  from 
$0  to  $200,000. 

AFFTC,  Edwards  AFB,  CA  Year  2000  Estimated  T&E  Costs 

$  200,000 

2.  ANCILLARY  AND  FUNCTIONAL  COMPUTER  ASSETS:  These  systems  are  generally 
developed  and  maintained  by  each  major  organization’s  information  management  support 
function  to  support  the  entire  activity  or  Command.  The  Naval  Air  Warfare  Center  Aircraft 
Division,  Patuxent  River,  MD’s  and  Aberdeen,  MD’s  estimates  below  represent  overall 
functional  costs  encompassing  activities  outside  those  range  sites,  whereas  the  estimate  for 
AFFTC  reflects  only  for  Edwards  AFB,  not  the  needs  of  the  Air  Force  Material  Command. 
Each  site  has  examined  its  information,  management,  base  support,  and  range  support  systems 
with  regard  to  Year  2000  impacts.  The  following  estimates  reflect  the  costs  to  repair  or  replace 
that  software  and  affected  hardware  platforms,  anticipating  that  some  system  components  will 
fail  plus  the  cost  to  do  some  level  of  situational  testing. 


Naval  Air  Warfare  Center  Aircraft  Division  Estimated  Business  System  Year  2000  Costs: 

$15,000,000 

Aberdeen  Proving  Ground  Garrison  Estimated  Business  System  Year  2000  Costs: 

$  6,000,000 
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AFFTC,  Edwards  AFB  Estimated  Business  System  Year  2000  Costs: 

$  200,000 

3.  GENERALIZATION  TO  THE  MRTFB  COMMUNITY:  The  wide  variance  in  these  honestly 
derived  Year  2000  compliance  costs  makes  the  T&E  generalization  question  most  difficult  to 
answer.  A  rough  average  of  all  costs  defined  in  this  survey  comes  to  $8,254,000  per  site  to 
correct  scientific  and  business  systems  for  Year  2000  problems.  Applied  across  all  MRTFB  sites, 
the  total  estimate  for  achieving  nominal  Year  2000  compliance  exceeds  $150,000,000.  This 
figure,  while  in  keeping  with  T&E’s  share  of  larger  DoD  estimates,  however,  is  largely  a  best 
guess.  The  estimates  from  the  sites  studied  were  not  rigorously  developed  based  on  detailed  fact. 
Their  wide  range  further  adds  to  the  uncertainty.  Moreover,  the  costs  to  identify  the  true  extent  of 
the  problem  were  not  really  calculated  into  the  estimates  provided.  Thus,  the  estimates  do  not 
reflect  the  discovery  cost  to  perform  inventories,  triage  “at-risk”  systems  and  interfaces  and 
establish  solid  configuration  management  practices  where  required.  Given  these  factors, 
combined  with  the  need  to  impress  on  management  that  the  real  problem  may  not  meet  the  eye, 
the  loosely  derived  estimate  may  well  prove  to  be  precipitously  low.  The  perplexing  problem  is 
that  to  produce  a  serious  Year  2000  business  case  requires  a  significantly  detailed  assessment  of 
the  real  Year  2000  impact  across  all  MRTFB  installations.  This  effort  in  and  of  itself  could  easily 
cost  more  than  $15,000,000  based  on  the  best  available  industry  estimates  of  10%  of  the  total 
estimated  implementation  cost. 

C.  INDUSTRY  TRENDS:  T&E  Year-2000  Team  participants  conducted  a  detailed  literature 
search  of  commercial  enterprises  offering  Year  2000  solutions.  Much  of  this  literature  was 
available  via  the  World  Wide  Web  (WWW).  The  Test  and  Evaluation  Community  Network 
(TECNET)  Home  Page  contains  a  growing  number  of  significant  DoD  related  Year  2000 
references.  This  page  is  http://tecnetl.jcte.jcs.mil:8000/.  A  number  of  team  participants  also 
attended  key  Year  2000  conferences  and  public  Federal  meetings  where  additional  commercial 
information  and  Year  2000  insights  became  available.  From  these  meetings,  the  team  identified 
two  innovative  industry  leaders  to  evaluate  via  direct  interaction.  These  organizations  included: 
OAO  Corporation  which  possessed  an  omnibus  task  order  from  the  General  Services 
Administration  (GSA)  and  DBSTAR  which  offered  a  unique,  but  unproved  data  oriented 
approach  to  Year  2000  assessment.  Appendix  E  contains  a  tabular  compilation  of  significant 
Year  2000  commercial  offerings  as  compiled  by  the  T&E  Year-2000  Team. 

1.  The  clear  mandate  within  the  recommended  industrial  trends  was  to  perform  a  detailed 
assessment  of  all  existing  code.  The  most  recommended  procedure  was  to  literally  parse  all  of 
the  code  for  instances  of  Year  2000  year  manipulations  that  could  create  serious 
misrepresentation  problems.  This  practice  goes  well  beyond  a  mere  inventory  of  code,  (which  is 
a  necessary  first  step).  Rather  it  requires  that  this  code  be  analyzed  in  great  detail.  Several 
vendors  and  private  organizations  experienced  in  Year  2000  problem  solving  reported  that 
attempts  to  analyze  code  for  date  instances  by  human  examination  only  meet  with  limited 
success.  Such  experiences  demonstrate  that  separate  groups  of  analysts  and  programmers  all 
examining  the  same  code  will  invariably  find  different  sets  of  instances.  Both  data  elements  and 
data  values  that  appear  to  represent  dates  to  one  group  may  not  be  at  all  apparent  to  another. 
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This  is  due  to  the  so-called  “creative”  nature  of  coding  without  standards.  Clearly,  tools  are 
needed.  A  number  of  powerful  code  parsing  tools  exist  for  this  purpose.  These  tools  generally 
evaluate  the  code  from  the  standpoints  of:  Calls  to  the  Operating  System,  Date  formats.  Variables 
containing  dates,  Buffers,  and  Year  defaults.  However,  most  of  these  parsers  are  largely  aimed  at 
mainframe  computers  running  a  large  complement  of  COBOL  programs.  The  more  diverse  the 
language  base  used,  as  is  the  case  in  T&E,  the  greater  the  odds  that  suitable  parsers  are 
unavailable,  much  less  the  necessary  compilers.  Thus,  T&E  investment  in  parsers  and  the 
knowledge  to  run,  or  worse  yet,  create  them  could  be  great.  The  cost  of  such  analysis  is  estimated 
at  $35,000  per  1,000,000  lines  of  COBOL  code,  assuming  a  homogeneous  code  base.  OAO,  the 
General  Services  Administration’s  (GSA)  Year  2000  vendor,  estimates  this  initial  assessment 
effort  consumes  about  10%  of  the  necessary  work  to  eradicate  the  Year  2000  problem. 

2.  Another  15%  of  the  Year  2000  effort,  according  to  OAO,  involves  assessing  and  testing  tools 
for  repairing  and  testing  for  compliance  once  the  original  diagnostics  have  been  performed. 
Assuming  the  completed  diagnostics  and  a  reasonable  tool  set,  the  next  10%  of  effort  involves 
planning  with  confidence  for  code  correction,  testing  and  implementation.  This  last  phase 
consumes  some  65%  of  the  overall  effort.  These  estimates  were  supplied  by  OAO  Corporation, 
which  is  the  firm  selected  by  GSA  to  support  and  help  coordinate  Year  2000  activities 
throughout  the  Federal  Government.  These  percentages  are  illustrated  in  the  FIGURE  2  Pie 
Chart.  FIGURE  3  applies  the  OAO  model  to  the  estimated  Year  2000  T&E  costs  (Business  and 
Scientific  computing). 


Representative  Year  2000  Profile 

GSA  Estimated  Cost 

(per  OAO  Corp  Study) 


Fix  &  Confirm 


Code 

Assessment 

10% 


Diagnostics 


65% 


Management 
10% 


15% 


FIGURE  2 
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T&E  Year  2000  Cost  Profile 

Figures  calculated  in  accordance  with  model  developed  under  GSA  contract  with  OAO 

All  percentages  are  based  on  the  total  implementation  cost,  which  the  T&E  Year  2000  team  estimated 

at  $150M. 


10% 

$15.0M 

Detailed  problem  assessment  /  business  case 
includes  2  %  ($3M)  for  problem  ID  &  planning 

10% 

$15.0M 

Assessment  of  existing  code  to  locate  suspects 

15% 

$22. 5M 

Tools,  diagnostics,  &  compliance  testing 

65% 

S97.5M 

Fix  and  confirm  * 

100  % 

$150M 

*  The  “fix”  figure  assumes  entire  cost  of  fixing  T&E  problems  will  be  borne  by  the  T&E  community. 
This  amount  may  be  reduced  by  gaining  commitment  from  services,  agencies,  etc.  to  assist  with 
solutions  involving  systems  they  support. 


FIGURE  3 

While  this  is  the  most  sensible  methodology,  other  alternatives  exist.  These  alternatives,  ranked 
for  practicality  include:  a  most  critical  systems  approach  whereby  crucial  systems  such  as  payroll 
are  attacked  in  sequence,  an  enterprise  approach  involving  a  holistic  top-down  assessment  of  the 
entire  enterprise,  and  a  re-engineering  approach.  The  critical  systems  approach  has  great  merit  so 
long  as  critical  system  interfaces  as  previously  discussed  are  factored  into  the  systems  evaluation 
rules.  The  enterprise  approach  may  have  merit,  but  requires  a  massive  management  commitment 
over  and  above  necessary  working  level  effort.  The  re-engineering  approach,  while  attractive  in 
concept,  cannot  not  practically  come  to  fruition  in  time  for  the  immutable  Year  2000  deadline.  It  is 
important  to  note  that  despite  the  selected  approach,  any  Year  2000  solution  demands  a  high  degree 
of  direct  user  involvement  in  all  phases  of  activity.  There  is  general  consensus  among  the  vendors 
that  any  turn-key  contractor  based  strategy  is  bankrupt. 

3.  The  T&E  Year-2000  Team  evaluated  one  promising  technology  to  help  ease  the  Year  2000 
code  assessment  burdens  noted  above.  Rather  than  parse  the  actual  code,  one  firm,  named 
DBSTAR,  suggested  that  the  actual  data  produced  from  the  code  held  significant  insights.  These 
data  could  be  assessed  for  highly  probable  data  patterns  concerning  the  manipulation  of  year 
based  data.  The  DBSTAR  tool  set  was  initially  developed  to  provide  a  map  of  legacy  systems  for 
purposes  of  intelligent  systems  re-engineering.  This  established  data  mapping  code  works  with 
singular  data  sources  such  as  a  column  of  like  data,  large  data  matrices  and  whole  systems  of 
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related  applications  based  data.  When  set  to  filter  for  year  related  data,  theoretically  the  results 
yield  instances  of  date  relevant  manipulations  and  isolates  real  date  activity  from  mere  date 
stamps.  The  problem  is  that  the  extent  of  fidelity,  as  of  July  1,  1996  remains  untested  and, 
therefore,  unproved.  While  the  concept  is  sound,  it  is,  however,  based  on  some  degree  of 
statistical  accuracy  yielding  less  than  a  100%  solution  set.  Nonetheless,  when  used  in 
conjunction  with  code  parsing  where  practical,  the  emerging  DBSTAR  approach  makes  sense. 

D.  RELATED  DOD  ACTIVITIES:  As  evidenced  by  the  growth  in  DoD  sponsored  Year-2000 
Home  Pages  on  the  World  Wide  Web  since  the  T&E  Year-2000  Team  initiated  its  activities,  all 
the  services  are  now  deeply  engaged  in  Year  2000  activities.  These  pages  are  rich  in  service 
based  findings  and  contain  many  vendor  specific  tools  and  solutions.  This  level  of  service 
activity  is  further  confirmed  by  direct  liaisons  established  between  the  T&E  Year-2000  Team 
and  the  Army,  Navy  and  Air  Force  headquarters  level  teams.  To  date,  most  of  these  teams  have 
produced  nothing  beyond  the  scope  of  what  is  reported  herein.  The  Air  Force  headquarters  C4 
team,  however,  has  devised  a  detailed  service  wide  action  plan  that  is  gaining  wide  recognition  in 
the  Federal  Government.  This  approach  follows  the  sequential  steps  of  awareness,  assessment, 
renovation,  validation  and  implementation.  Under  this  tightly  scheduled  plan,  1999  becomes  the 
year  of  testing.  The  salient  fact,  however,  is  that,  as  expected,  the  services  are  taking  this  matter 
very  seriously.  Another  important  contribution  came  via  the  well  received  Year  2000  study 
performed  for  DoD  by  the  Mitre  Corporation.  It  is  also  significant  to  note  that  certain  Federal 
Acquisition  Regulations  have  already  been  modified  and  will  continue  to  be  changed  to  rectify 
Year  2000  matters  in  Federal  procurements. 

Finally,  a  May  1996  publication,  the  Naval  Information  Systems  Management  Center  (NISMC) 
Information  Update,  provided  the  following  ASD(C3I)  Year  2000  guidance: 

(1)  Ensure  vital  systems  do  not  fail  from  date  change; 

For  Existing  Systems,  both: 

-Take  corrective  action  during  normal  systems  maintenance  or  upgrades,  and 

-  Embedded  systems  may  need  ‘out  of  cycle’  maintenance. 

For  New  Systems: 

-  Ensure  vendors  will  warrant  fault  free  performance  in  processing  data  and  date 

dependent  data  (including,  but  not  limited  to  calculating,  comparing  and 

sequencing)  from  contract  date,  not  the  year  2000. 

(2)  Report  defects  in  key  systems  projected  to  extend  into  or  beyond  year  2000  through 
service  or  agency  chain  of  command. 

E.  FINDINGS  SUMMARY:  The  Year  2000  problem  came  seemingly  out  of  nowhere  and 
slapped  a  huge  prospective  bill  on  the  DoD  doorstep.  As  noted  above,  just  how  large  this  bill 
will  be  for  the  T&E  community  is  difficult  to  ascertain.  Unlike  most  business  computing  at 
corporate  levels,  T&E  computer  assets  differ  greatly  and  are  widely  dispersed  within  range  sites 
making  the  matter  of  approximating  costs  to  find  and  eliminate  the  problem  circumstantial  and 
exceedingly  difficult  to  substantiate  without  significant  investment  in  impact  analysis.  According 
to  the  testimony  of  managers  and  engineers  interviewed  for  this  task  and  the  results  of  the  tests, 
the  Year  2000  flaw  is  present  in  at  least  some  scientific  and  support  computing  at  the  ranges,  but 
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its  true  dimensions  are  unknown.  Even  though  the  Year  2000  conversion’s  impact  on  range 
systems  does  appear  on  the  surface  to  be  minor,  a  lack  of  complete  inventories  of  T&E  system 
computer  resources  at  the  three  sites  studied  limited  identifying  the  true  extent  of  what  might  be 
at  risk.  Further,  without  more  extensive  testing,  the  team  can  not  say  with  certainty  whether  the 
perception  of  the  Year  2000  problem  is  really  relatively  minor  or  whether  more  serious 
problems,  undetectable  by  casual  inspection,  are  lurking  beneath  the  surface.  Significant  Year 
2000  compliance  problems  seem  to  be  found  in  older  mainframe  or  stand-alone  systems  and  their 
operating  system  software.  Problems  are  almost  universal  in  PCs,  but  the  turnover  rate  of  these 
computers  minimizes  the  Year  2000  threat  since  replacements  are  known  to  be  compliant. 
Finally,  heightened  awareness  of  the  potential  problem  has  been  a  major  benefit  of  this  quick 
look  exercise.  It  is  through  such  heightened  awareness  that  progress  shall  be  made  across  the 
board. 
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SECTION  3:  RECOMMENDATIONS:  Based  on  the  statements  of  interviewees  and  the 
evidence  from  its  cursory  research  and  analysis,  the  T&E  Year-2000  Team  does  not  see  a 
compelling  reason  to  immediately  launch  localized  teams  of  experts  at  the  engineering 
applications  or  supporting  hardware/firmware  to  ferret  out  all  offending  date  instances  in  T&E. 
This  is  not  to  imply  that  the  Team  is  satisfied  that  Year  2000  impacts  are  not  hiding  in  scientific 
and  engineering  systems  in  the  T&E  community.  The  fact  is  that  they  are  and  will  undoubtedly 
remain  hidden  in  some  applications  and  in  some  embedded  code  until  they  are  discovered,  either 
by  intent  or  by  accident!  They  do  not  appear,  however,  to  be  as  mission  threatening  as  is  the 
case  with  business  applications.  The  Team  feels  that  as  awareness  grows  scientists,  engineers, 
and  technicians  will  be  alert  to  Year  2000  instances  and  more  and  more  problem  situations  will 
be  resolved.  The  Team  also  feels  that  there  is  sufficient  time  available  to  convert  systems  to  Year 
2000  compliance  if  awareness  campaigns  are  sufficiently  promoted  and  timely  actions  effected. 
Awareness  was  a  chief  concern  at  the  outset,  but  the  Team  has  seen  the  rise  of  several  new 
efforts  in  DoD  in  response  to  this  problem  with  a  concern  for  both  business  and  weapons 
systems. 

A.  RECOMMENDATION  1 :  There  is  the  need  to  establish  a  centralized  facility  equipped  with 
selected  Year  2000  tools,  an  established  Year  2000  methodology,  established  access  to  proven 
Year  2000  vendors  such  as  are  available  through  GSA,  and  a  small  cadre  of  experts  trained  in  the 
methodology,  the  tools,  and  in  assisting  requesting  commands  to  identify  and  resolve  Year  2000 
problems  throughout  the  T&E  community,  and  coordinate  and  track  the  effort  DoD-wide. 
Therefore,  the  Team  recommends  the  establishment  of  a  “T&E  Year-2000  Clearing  House”  to 
assist  DoD  components  resolve  their  Year  2000  transition  problems.  As  noted  in  Section  1., 
Year  2000  conversion  in  DoD  is  a  major  management  issue.  Technical  considerations,  as 
pervasive  and  challenging  as  they  may  be,  are,  nevertheless,  secondary  when  compared  to 
managing  the  effort.  That  is  why  the  Team  considers  that  a  focused  approach  to  the  Year  2000 
conversion  effort  is  required.  Otherwise  each  command  must  pursue  the  tum-of-the-century 
transition  independently  with  attendant  lose  of  uniformity  and  economics.  Operating 
independently,  commands  may  or  may  not  acquire  a  Year  2000  tool  set,  hire  contractors,  assign 
staff  and  develop  expertise  in  solving  Year  2000  problems  they  consider  unique  to  their 
individual  environments.  Moreover,  once  the  crisis  has  passed,  such  investments  will  no  longer 
be  of  use  and  would  be  considered  lost  as  sunk  costs.  These  costs  could  be  significant  if  repeated 
at  every  range  and  will  only  increase  as  the  elapse  of  time  makes  repairs  more  paramount.  Thus, 
the  “Clearing  House”  approach  provides  top  T&E  management  a  cost  effective  vehicle  to  ensure 
that  attention  is  focused  on  discovering  Year  2000  problems  everywhere,  uniformly  resolving 
them  ,  and  reporting  results. 

An  immediate  task  of  this  team  would  be  to  develop  certification  criteria  for  T&E  System  Year 
2000  compliance.  The  team  should  be  required  to  integrate  its  efforts  with  established  Year  2000 
Offices  at  the  DoD  and  Service  levels.  Given  the  economy  of  scale  through  this  clearing  house 
approach,  2%  of  its  estimated  investment  for  immediate  centralized  problem  identification  and 
planning  per  the  OAO  model  seems  prudent.  Thus,  the  team  recommends  an  immediate  “start¬ 
up”  investment  of  $3M  for  establishment  and  operations  of  the  “T&E  Year-2000  Clearing 
House”  in  FY97  with  future  funding  based  on  measured  “Clearing  House”  contributions.  The 
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ultimate  objective  would  be  to  make  the  “Clearing  House”  operation  self  sufficient  by  1999 
through  its  positive  contributions  to  the  T&E  community  and  beyond. 

B.  RECOMMENDATION  2.  Through  the  “Clearing  House”,  aggressively  promote  awareness 
campaigns  throughout  the  T&E  community.  Utilize  the  Tri-Service  Range  Commanders  Council 
(RCC)  Working  Groups  (data  reduction  and  computers,  electronic  trajectory  measurement, 
signals  measurement,  meteorology,  telecommunications  and  timing,  range  safety,  optical 
systems)  to  promulgate  Year  2000  issues  and  investigate  and  report  on  areas  of  vulnerability  or 
compliance.  Likewise,  energize  management  support  throughout  the  Executive  Agent  to  focus 
awareness  and  necessary  compliance  activities  throughout  the  T&E  community.  Emphasis 
should  also  be  given  via  electronic  means  such  as  the  World  Wide  Web  using  as  many  sites  as 
possible  to  popularize  Year  2000  success  stories,  techniques  and  winning  strategies.  A  good  start 
may  be  to  promulgate  the  contents  of  this  report  throughout  the  T&E  community  for  critical 
review  and  comment.  Such  activity  tends  to  heighten  Year  2000  awareness  and  spirit  the  dialog 
necessary  to  engage  a  timely,  proactive  Year  2000  stance  throughout  the  entire  T&E  community. 
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APPENDIX  A: 


MAR  19  1996 


MEMORANDUM  FOR  CNO  (N91) 

FROM:  Chairman,  T&E  Board  of  Operating  Directors 
4225  Logistics  Ave,  Suite  2 
Wright-Patterson  AFB  OH  45433-5714 

SUBJECT:  Test  and  Evaluation  Software  Conversion  for  the  Year  2000  Changeover 
(DTSE&E  Memo,  Not  Dated) 

1.  Per  the  subject  memorandum,  the  Board  of  Operating  Directors  (BoOD)  was  tasked  to 
establish  a  program  to  ensure  that  all  systems  expected  to  migrate  through  the  Year  2000  are 
compliant  with  SECDEF  Memorandum,  dated  27  November  1995.  Specifically,  apian  of  action 
and  milestones  (POA&M)  was  developed  to  assess  T&E  vulnerability  to  the  Year  2000  problem, 
define  the  related  business  and  technical  impacts,  review  other  organization’s  Year  2000  efforts, 
and  identify  a  range  of  options  for  the  T&E  community  to  address  this  issue.  This  POA&M  for 
the  Year  2000  Software  Issue  is  attached.  Recommended  funding  source  for  execution  of  the 
POA&M  are  T&E  Corporate  Information  Management  (CIM)  Central  Funds.  The  estimated 
funding  required  was  $60K. 

2.  The  subject  tasker  also  requested  a  briefing  on  the  plan  of  action  to  provide  a  plan  to  the 
Defense  Test  and  Training  Steering  Group  or  the  T&E  CIM/EI  Steering  Council,  as  appropriate, 
in  March  1996.  The  T&E  CIM  Director,  Col  Spencer,  is  prepared  to  present  this  briefing  when 
directed. 

3.  The  BoOD  POC  for  this  action  is  Col  Spencer,  T&E  Joint  Program  Office  (JPO),  Director, 
DSN  858-4755. 


\signed\ 

FRANCIS  C.  GIDEON,  JR 
Major  General,  USAF 
Chairman 


Attachment: 

POA&M 

cc:  (listed  on  next  page) 
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cc: 

HQ  USAF/TE 

SAUS-OR 

AMSTE-CG 

Commander  NAWCWD 

AMSTE-TA 

NAWCAD  (5.1) 

AFDTC/CD 

HQ  USAF/TER 

DACS-TE 

CNO  (N913) 

JPO(T&E) 

NAWDWD/52D000D 


Year-2000  Problem 

Near  Term  Plan  of  Action  and  Milestones  for  T&E 


OBJECTIVE:  The  objective  of  this  POA&M  is  to  develop  a  workable  plan  for  the  T&E 
community  to  deal  with  a  "Year-2000  Problem"  that  involves  year  representation  in  automated 
systems  and  software.  This  POA&M  is  in  response  to  an  OSD/DTSE&E  Memorandum  date 
January  1996. 

SCOPE:  Assess  T&E  vulnerability  to  the  Year-2000  problem,  define  the  related  business  and 
technical  impacts,  review  other  organization's  Year-2000  efforts  and  identify  a  range  of  options 
for  the  T&E  community  to  address  this  issue. 

BACKGROUND :  There  is  a  real  risk  that  automated  systems,  including  software  applications, 
will  yield  inaccurate  results  at  or  near  the  century  change  if  the  year  is  represented  using  only 
two  digits.  This  problem  manifests  itself  when  the  year  becomes  "00".  As  the  century  cannot  be 
determined,  the  computation  on  the  "00"  year  can  lead  to  totally  inappropriate  answers.  Often  a 
"00"  or  "99"  in  the  automated  year  representation  indicates  an  accepted  "default"  condition.  In 
such  cases,  the  year  problem  can  manifest  itself  as  early  as  the  year  1999.  This  problem  also 
immediately  affects  any  forecasting  system  that  expresses  the  year  in  two  digits  and  projects  into 
the  next  century.  Even  if  a  system  is  updated  to  account  for  four  digit  year  representation,  it  is 
still  vulnerable  to  other  systems  that  feed  it  two  digit  year  information.  Such  information  is 
frequently  embedded  in  "intelligent  numbers",  such  as  Job  Order  Numbers.  Even  many  personal 
computers  have  design  susceptibility  to  this  fault. 

ASD  (C3I)  has  notified  all  DoD  of  the  impending  risk.  The  T&E  community  is 
vulnerable  in  real-time  operations  such  as  weapon  system  testing,  range  and  flight  safety 
systems,  and  time  critical  data  processing  where  two  digit  year  representation  may  be  involved. 
The  full  range  of  business  systems  that  support  T&E  are  also  in  jeopardy  of  failure  at  or  before 
the  Year  2000.  The  recent  "Year  2000  Blueprint  for  Success"  conference,  heavily  attended  by 
DoD,  revealed  that  as  many  as  50%  of  all  systems  expected  to  still  exist  by  2000  may  not  be 
Year-2000  compliant.  Conference  speakers  noted  that  a  top  down  approach  is  required  to  achieve 
success.  A  SECDEF  Memorandum  of  27  November  1995  establishes  Year-2000  guidelines  for 
new  start  acquisition  programs.  Other  DoD  initiatives  are  taking  shape. 

APPROACH:  Given  the  pervasive  nature  of  the  Year-2000  problem  and  the  ongoing  initiatives 
to  address  it,  the  T&E  approach  should  be  proactive  but  not  duplicative.  To  formulate  such  an 
approach,  we  propose  forming  a  small  group  of  T&E  experts  to  answer  a  number  of  key 
questions:  determine  the  evolving  guidance  and  other  initiatives  at  service  and  related  functional 
areas;  assess  the  extent  of  T&E  specific  vulnerabilities  and  how  to  pinpoint  them;  and  heighten 
universal  T&E  awareness  of  the  Year-2000  problem  and  the  range  of  potential  methods  and 
solutions  that  can  be  brought  to  bear.  An  assessment  criteria  may  be  developed  by  which  high 
leverage  T&E  systems  are  identified  early  and  targeted  for  Year-2000  upgrades.  Issues  dealing 
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with  the  timing  of  cross-functional  changes  must  also  be  understood.  These  factors,  and  other 
pertinent  Year-2000  information  must  then  be  folded  into  a  comprehensive  Year-2000  plan  for 
the  T&E  community.  The  team  will  examine  the  Year-2000  issue,  including:  the  extent  of  the 
problem  in  the  T&E  community,  best  practices  for  identifying  vulnerable  systems  and 
applications,  best  practices  for  rectifying  the  Year-2000  problem  when  identified,  means  of 
identifying  and  addressing  necessary  interfaces  with  systems  from  other  functional  areas, 
methods  for  dealing  with  vendor  supplied  software,  methods  for  documentation  and  other  best 
practices  from  Government  and  industry. 

PROPOSED  STUDY  TEAM:  The  approach  to  developing  such  a  plan  involves  establishment 
of  a  short  term  team  focused  on  the  Year-2000  problem.  This  team,  chaired  by  Mr.  Jerry  Brown 
of  the  Naval  Air  Warfare  Center  -  Aircraft  Division,  Patuxent  River,  Maryland,  will  be  composed 
of  six  BoOD/RCC  selected  members.  Three  will  represent  the  services  from  the  T&E  business 
community  and  three  will  represent  the  services  from  the  T&E  engineering  community. 

SCHEDULE:  The  team  will  be  stand-up  in  late  March  1996.  It  will  have  90  days  to  conduct 
research  and  prepare  a  comprehensive  plan.  It  will  report  this  plan  to  the  BoOD. 

RESOURCES:  The  support  of  this  team  will  require  S30K  for  required  travel  and  attendance  at 
scheduled  meetings.  Another  $30K  is  required  for  contractor  administrative  support.  Funding 
source  is  either  T&E  CIM  funds  or  BoOD  requested  OSD  funding  to  respond  to  this  OSD  task. 
Team  salary  shall  be  borne  by  the  providing  organizations. 

LOGISTICS:  The  team  is  at  liberty  to  identify  its  own  logistics  needs  within  the  constraints  of 
available  resources.  The  T&E  CIM  office  will  assist  in  making  necessary  arrangements. 
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MEMORANDUM  FOR  BOARD  OF  OPERATING  DIRECTORS 

ATTN:  MAJ  GEN  F.  C.  GIDEON,  JR ,  CHAIRMAN 
HQ  AFMC/DO,  4225  LOGISTICS  AVENUE,  SUITE  2, 
WRIGHT-PATTERSON  AFB,  OH  45433-5714 

SUBJECT:  Year  2000  Software  Issues  Funding  —  INFORMATION  MEMORANDUM 

1 .  The  Board  of  Operating  Directors  approved  the  Y ear  2000  Software  Issues  PO  A&M  and 
recommended  funding  it  from  T&E  CIM.  During  the  T&E  CIM  Steering  Council  prebriefing, 
Mr.  Burt  observed  that  the  Year  2000  Software  Issue  effort  did  not  involve  business  process 
reengineering  and  therefore  is  not  suitable  for  T&E  CIM  funding. 

2.  After  reviewing  all  potential  funding  alternatives  and  the  POA&M  tasks,  the  JPO(T&E)  has 
rescoped  the  tasks  and  reduced  the  cost  for  the  quick  action  team  (see  attachment).  We  will 
implement  the  following  actions  and  modifications  to  the  POA&M: 

a.  The  JPO(T&E)  will  provide  TDY  funding  (less  than  $10K)  for  the  study  team  (funds 
for  study  team  activity  was  included  in  the  approved  JPO  administrative  plan),  and 

b.  The  study  team  will  request  a  limited  amount  of  clerical  support  (about  5  days)  from 
Patuxent  River  NAS  —  the  organization  supporting  the  team  leader,  Jerry  Brown. 

C.  The  JPO(T&E)  will  sent  the  attached  letter  to  the  survey  sites. 

3.  The  JPO(T&E)  point  of  contact  for  this  effort  is  Colonel  Ken  Spencer,  DSN  858-4755. 


TODD  STEVENSON,  GS-15 
Acting  Director 

1  Attachment 

Action  Plan  for  T&E  Survey  Team  with  cover  letter 
cc: 

Commander,  U.S.  Army  Test  and  Evaluation  Command  (MG  Richard  W.  Tragemann),  Aberdeen 
Proving  Ground,  MD  21005-5055 

RADM  Dana  B.  McKinney,  Commander,  Naval  Air  Warfare  Center  Weapons  Division,  Code 
000000D,  1  Administrative  Circle,  China  Lake,  CA  93555-6001 
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MEMORANDUM  FOR  COMMANDER,  ABERDEEN  TEST  CENTER 

COMMANDER,  AF  FLIGHT  TEST  CENTER 
COMMANDER,  NAWC  AIRCRAFT  DIVISION 

SUBJECT:  Year  2000  Software  Issues  Survey  Team 

Senior  government  and  industry  officials  have  identified  a  potential  serious  problem 
associated  with  the  date  coding  that  will  impact  most  computers  and  software  in  the  Year  2000 
(see  attachment).  The  Test  and  Evaluation  Board  of  Operating  Directors  (BoOD)  has  established 
a  quick  action  team  to  survey  the  selected  Service  ranges  and  identify  the  risks  of  this  serious 
problem  to  the  T&E  community.  In  the  June,  the  BoOD  will  distribute  a  report  of  this  team’s 
findings  to  every  T&E  organization  to  help  mitigate  the  impacts  of  this  potential  problem. 
Respectfully  request  your  facility  cooperate  with  this  study  team  on  a  minimum  interference 
basis  and  help  to  provide  the  T&E  community  an  assessment  of  the  severity  of  this  problem. 


1  Attachment 

Action  Plan  for  T&E  Survey  Team 


TODD  STEVENSON,  GS-15 
Acting  Director 
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MILLENNIUM  DATE  CHANGE  SURVEY 


ACTION  PLAN  FOR  T&E  SURVEY  TEAM 

1.  The  dimensions  of  the  millennium  date  change ,  commonly  called  the  Year  2000  problem,  are 
enormous.  Given  our  reliance  on  computers  ,  the  failure  of  systems  to  operate  properly  can  mean 
anything  from  minor  inconvenience  to  major  catastrophe:  Licenses  and  permits  not  issued. 
Payroll  checks  not  cut.  Personnel,  medical  and  academic  records  malfunctioning.  Errors  in 
banking  and  finance.  Accounts  not  paid  or  received.  Inventory  not  maintained.  Vital  supplies 
not  ordered  or  received.  Security  locks  not  functioning.  WEAPONS  SYSTEMS  NOT 
FUNCTIONING  PROPERLY.  Clearly,  the  Year  2000  conversion  should  be  of  substantial 
concern  to  DoD  executives  in  both  business  and  technical  functions. 

2.  For  the  last  30  or  40  years,  programmers  have  stored  date  information  in  “mm/dd/yy”  format 
versus  “mm/dd/yyyy”  format  to  conserve  space  in  disk  storage  and  computer  memory.  They 
adjusted  computations  to  take  the  two-digit  year  into  consideration  when  computing  time 
periods,  ending  dates,  and  the  like.  And  they  used  the  two-digit  date  to  control  certain  program 
operations  or  for  special  purposes.  At  that  time,  most  programmers  and  project  managers  figured 
that  their  programs  would  not  last  into  the  twenty-first  century.  They  were  trying  to  perform  a 
service  to  their  management  by  conserving  expensive  and  limited  disk  space  and  computer 
memory.  Adding  two  century  digits  to  a  date  field  could  add  several  megabytes  of  storage 
requiring  procurement  of  a  disk  that  then  cost  upwards  of  $20,000.  It  made  economic  sense  to 
lop  off  the  two  century  digits.  This  practice  applied  to  some  scientific  as  well  as  business 
programming  and  continues  today  where  traditional  methods  are  still  practiced,  although  popular 
modem  software  languages  now  require  the  four-digit  date  field  to  be  used. 

3.  Foremost  in  deciding  what  to  do  is  estimating  the  extent  of  the  problem.  As  a  first  step  in 
arriving  at  this  estimate  for  solving  Year  2000  problems  at  T&E  Ranges,  the  T&E  Board  of 
Operating  Directors  (BoOD)  has  established  a  quick  action  (90  day)  team  to  focus  on  the 
problem.  This  Year  2000  team  is  comprised  of  representatives  from  each  service.  The  team 
will  use  the  case  study  approach  concentrating  on  one  range-site  per  service.  It  will  attempt  to 
assess  the  vulnerability,  impact,  range  of  options,  and  cost  of  fixes  at  each  of  the  three  sites. 
Generalizing  from  this  information,  the  resulting  findings  and  analysis  will  form  the  basis  for 
scoping  and  recommendations  for  resolution  of  the  problem  across  all  Ranges.  This  alternative 
is  within  the  team’s  practical  means,  involves  all  services  using  limited  team  resources,  is 
scaleable  and  can  yield  a  methodologically  sound  approach  for  others  to  follow.  Data  gathering 
will  be  by  means  of  the  interview  method.  Review  and  analysis  of  a  variety  of  computer- 
related  resource  reports  provided  by  the  Range  sites  will  augment  the  interviews. 
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4.  The  Range  sites  selected  are  TECOM,  Aberdeen,  MD;  AFFTC,  Edwards  AFB,  CA;  and 
NAWCAD,  Patuxent  River,  MD.  The  Year  2000  team  initiated  interviews  at  some  sites  the  week 
of  15  April  and  expects  to  complete  this  phase  of  its  plan  before  the  end  of  May.  I  encourage 
your  support  of  this  effort  at  these  places.  The  BoOD  POC  for  this  action  is  Col  Ken  Spencer, 
T&E  Joint  Program  Office  (JPO),  Director,  DSN,  858-4755.  The  Year  2000  team  lead  is  Jerry 
Brown,  Naval  Air  Warfare  Center  Aircraft  Division,  Patuxent  River,  MD,  DSN  342-3335. 


****************************************************************************** 
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APPENDIX  B: 

STUDY  METHODOLOGY  OF  THE  T&E  YEAR-2000  ASSESSMENT  TEAM 

The  T&E  Corporate  Information  Management  (CIM)  office  in  the  Joint  Program  Office  for  T&E 
(JPO(T&E))  proposed  formation  of  a  T&E  Year-2000  Assessment  Team  to  the  Board  of 
Operating  Directors  (BoOD)  for  T&E.  The  proposal  was  approved  by  the  BoOD  on  March  5, 
1996.  The  team  was  assembled  under  the  leadership  of  Mr.  Lloyd  (Jerry)  Brown  of  the  Naval  Air 
Warfare  Center  Aircraft  Division,  Patuxent  River,  Maryland  in  late  March.  The  tri-service  team 
began  meeting  on  April  3, 1996.  The  final  report  was  due  to  the  JPO(T&E)  by  early  July  1996. 

A.  SPECIFIC  TASKING:  The  T&E  Year-2000  Team  was  tasked  to  develop  a  workable  plan  for 
the  T&E  community  to  deal  with  the  "Year-2000  Problem".  This  plan  is  to  assess  T&E 
vulnerability  to  this  problem,  define  the  related  business  and  technical  impacts,  review  other 
organization's  Year  2000  efforts  and  identify  a  range  of  options  for  the  T&E  community  to 
address  this  issue. 

B.  ALTERNATIVES  CONSIDERED:  The  T&E  Year-2000  Team  considered  three  leading 
alternatives  to  achieve  its  tasking  within  the  assigned  schedule: 

1.  TOP-DOWN  WALL-TO-WALL  SURVEY:  The  team  seriously  considered  conducting  a  wall- 
to-wall  survey  of  all  software  running  within  the  T&E  community  as  a  first  step  to  assess  the 
impact  of  the  Year  2000  problem.  Some  existing  resources,  such  as  the  T&E  CIM  Automated 
Information  System  (AIS)  study  and  the  Joint  Test  Assets  Database  (JTAD)  were  evaluated  as 
starting  points.  Upon  further  examination,  however,  neither  of  these  resources  were  sufficiently 
detailed  in  terms  of  Year  2000  related  information  to  yield  meaningful  results.  Moreover,  these 
resources,  each  resulting  from  top-down  surveys  of  their  own,  took  far  longer  than  90  days  to 
compile.  Thus,  such  an  approach  was  deemed  impractical  for  the  near  term.  The  team  also  felt 
that  the  services  would  eventually  call  for  such  extensive  surveys,  making  the  T&E  effort  in  this 
area  duplicative  at  best. 

2  BENCHMARKING:  The  team  also  considered  conducting  a  formal  benchmark  study  on  an 
organization  similar  in  nature  to  the  DoD  T&E  infrastructure.  This  idea  was  abandoned  when  the 
question  of  a  suitable  study  partner  with  close  parallels  to  the  overall  DoD  T&E  community  in 
diversity  and  complexity  became  too  difficult  to  answer.  The  team  felt  the  extent  of  general 
acceptance  of  the  Year  2000  transition  problem  in  April  1996  was  still  too  tenuous,  even  if  a 
suitable  benchmark  study  partner  were  to  be  identified. 

3.  CASE  STUDY  APPROACH:  The  team  also  considered  focused  case  studies  within  identified 
portions  of  the  T&E  Major  Range  and  Test  Facilities  Base  (MRTFB).  This  approach  used 
existing  team  resources  to  the  fullest  possible  extent.  The  team  felt  that  the  findings  from  this 
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approach  could  be  scaled  for  rough  order  of  magnitude  cost  estimates  and  methodological 
approaches.  This  alternative  was  selected. 

C.  METHODOLOGY  ADOPTED:  The  T&E  Year-2000  Team  adopted  a  case  study  approach 
combined  with  a  complete  survey  of  existing  commercial  trends  toward  resolving  Year  2000 
issues.  The  case  studies  applied  to  the  three  MRTFB  facilities  represented  on  the  T&E  Year- 
2000  Team.  These  facilities  included:  the  Naval  Air  Warfare  Center  Aircraft  Division,  Patuxent 
River  Maryland;  The  Air  Force  Flight  Test  Center,  Edwards  Air  Force  Base,  California;  and  the 
Aberdeen  Test  Center,  Aberdeen,  Maryland.  The  Army’s  Test  and  Evaluation  Command,  which 
has  oversight  for  all  Army  Development  T&E  activities,  also  participated  as  a  contributor.  The 
team  was  also  augmented  by  direct  consultation  with  Army,  Navy  and  Air  Force  T&E 
participants  serving  on  service  based  Command- wide  Year-2000  teams.  The  T&E  Year-2000 
Team  choose  to  use  an  interview  method  to  collect  relevant  Year  2000  information  from  selected 
T&E  Field  Activity  leaders.  A  copy  of  the  agreed  upon  interview  questionnaire  is  attached.  The 
team  focused  primarily  on  T&E  scientific  processing  systems  operating  within  the  MRTFB.  It 
also  examined  T&E  support  tools  often  maintained  within  the  base  infrastructure  level  as  a 
secondary  priority.  Finally,  the  team  considered  the  large  scale  business  systems  affecting  T&E 
which  are  frequently  dependent  upon  CDA  organizations  or  other  non-T&E  entities.  Early  in  its 
existence,  the  team  also  agreed  upon  a  format  for  this  final  report  and  a  schedule  of  necessary 
events. 
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Questionnaire  -  Year  2000  Survey  Team 

1 .  To  what  extent  does  your  organization  directly  support  T&E? 

2.  What  is  your  core  T&E  function? 

3.  Are  you  aware  of  the  Y ear-2000  issue? 

a)  If  aware  -  How  are  you  affected  (mission  critical  (e.g.  safety  system),  minor 
impact  (date  on  Xerox  machine,  phone  LCD),  etc)? 

b)  If  unaware,  do  you  have  resources  to  assign  to  assess  the  impact? 

4.  What  is  being  done? 

a)  External  direction? 

b)  Local  plans/action? 

5.  Do  you  have  a  complete  inventory  of  all  computer  resources  (hardware,  software, 

firmware  and  archival  systems). 

6.  Do  you  know  which  of  your  systems/platforms/computers  are  affected? 

7.  To  what  extent  do  external'  interfaces  affect  your  internal  operations  (e.g.  Flight 
Scheduling,  supply,  finance) 

8.  What  are  your  estimated  costs  to  become  year-2000  ready 

9.  Are  there  other  organizations  you  support  or  are  supporting  you  that  we  should  talk 
to? 

****************************************************************************** 
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APPENDIX  C: 


T&E  YEAR-2000  TEAM  INTERVIEW  RESULTS 


NAVAL  AIR  WARFARE  CENTER  -  PATUXENT  RIVER.  MARYLAND 
Mr.  George  Rvan  14/15/961. 

Mr.  Ryan  serves  as  the  director  of  the  Atlantic  Range  and  Facilities  at  NAWCAD.  He  was 
generally  aware  of  the  Year  2000  issue.  He  expressed  a  willingness  to  spread  the  word  among  his 
Department  heads.  He  did  not  have  a  personal  assessment  of  the  scope  of  the  problem  or  the 
cost  to  repair  it,  but  felt  it  did  have  relevance  to  his  organization.  He  was  most  supportive  of 
further  investigation  of  the  problem. 

Mr.  Ron  Runvon  (4/17/96). 

Mr.  Runyon  serves  as  the  Deputy  Comptroller  at  NAWCAD.  He  was  generally  aware  of  the 
Year  2000  issue.  He  was  most  concerned  with  the  ability  of  Central  Design  Agents  (CD As)  who 
support  feeder  systems  such  as  NIFFMS,  NALCOMIS,  DCPDS  to  resolve  their  Year  2000 
problems  in  an  effective  way  before  they  affect  NAWCAD  corporate  systems.  He  felt  he  was 
largely  dependent  on  the  Information  Management  Department  (IMD)  to  resolve  any  lingering 
Year  2000  issues  within  local  business  systems  upon  which  he  must  rely.  He  was  fully  aware  of 
the  ORACLE  four  digit  date  field  convention.  He  felt  archival  data,  which  is  used  frequently, 
was  particularly  vulnerable.  He  cited  RAPS,  Travel  On-Line,  NIFMAS,  PAXIS  and  the 
Command  Workload  Data  Base  as  the  key  systems  upon  which  he  relies.  He  expressed  a 
willingness  to  be  part  of  the  solution.  He  will  assign  a  Comptroller  lead  to  inventory  all  systems 
and  assess  priorities  ,e.g.,  the  current  payroll  system  has  two  digit  date  fields.  He  felt  every 
system  that  produced  output  through  precalculation  required  scrutiny  (e.g.  all  invoices).  He 
expressed  a  strong  need  for  IMD  support.  He  felt  this  work,  particularly  on  current  systems, 
would  have  to  be  accomplished  at  night  or  over  weekends  on  overtime.  The  workload  with  the 
increased  Patuxent  River  population  will  be  huge  on  its  own  right. 

Production  systems  involve  current  transactions  and,  as  such,  are  dynamic  systems.  He  also  felt 
much  could  be  found  and  corrected  through  periodic  data  maintenance  activities  in  so  far  as 
archived  data  were  concerned  as  no  transactions  are  typically  ran  against  such  data.  He  expressed 
a  need  to  reach  out  to  CDA  POCs  and  PMs  to  express  our  concern  for  their  proactive  response. 

Mr.  Chuck  Lancaster  f4/17/96T 

Mr.  Lancaster  heads  the  Scientific  and  Engineering  programming  effort  for  NAWCAD,  Patuxent 
River.  His  focus  is  on  Computer  Aided  Software  Engineering  (CASE)  tools,  Training  Ranges, 
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and  the  reduction  of  Telemetry  and  TSPI  data.  Computational  Fluid  Dynamics  (CFD)  and 
Structures  are  now  largely  done  by  the  engineering  competencies,  4.2  and  4.3.  He  was  generally 
aware  of  the  Year  2000  issue.  He  maintains  some  300  programs.  These  programs  are  generally 
20  years  old.  They  are  largely  written  in  FORTRAN  with  more  recent  ones  in  C++. 
Photogramteric  data  reduction  programs  use  Julian  code  for  dates.  Telemetry  input  comes  in 
IRIG  Julian  date  format.  He  possesses  an  87  page  abstract  book  listing  these  programs  and  their 
nature: 

Description  of  the  Application/Program 

Capability/Utilization 

Name 

Program  or  Sub-program 
Aircraft  or  projects  supported 
In-house  or  commercial 
Date  of  last  update  or  review 
T&E  areas  supported 
Hardware  required 
Host 

Operating  system 
Threading  (multiple  or  single) 

Network  association(s) 

Unique  features 
Limitations 

He  feels  a  test  plan  is  required  to  seek  and  isolate  Year  2000  instances,  examine  the  potentially 
susceptible  code,  do  the  trade-offs,  and  make  the  fix.  He  will  assign  a  Year  2000  lead  to  examine 
his  computer  systems  for  Year  2000  impact  and  provide  the  findings  to  this  team.  He  suggested 
further  investigation  be  conducted  in: 

Metrology  -  Mr.  Jimmy  Fairfax 

Avionics  and  Mission  Technology  -  Mr.  Dan  Dickey 

Mr.  Terry  Collom  (4/17/96). 

Mr.  Collom  is  responsible  for  instrumentation  and  its  fabrication  at  NAWCAD,  Patuxent  River. 
He  was  made  aware  of  the  Year  2000  issue  through  a  television  spot  he  saw  the  preceding  night. 
He  sincerely  felt  the  Year  2000  issue  had  minimal  impact  at  first  blush.  He  agreed  with  Mr. 
Rymer  (see  below)  who  laid  the  problem  in  the  hands  of  the  suppliers,  be  they  maintenance 
contractors  or  Original  Equipment  Manufacturers  (OEM).  He  was  concerned  about  support 
systems  such  as  Supply,  which  could  affect  his  logistics  flow.  He  agreed  to  have  the  problem 
examined  more  closely  in  his  department. 

The  departmental  report  indicated,  as  expected,  that  the  effect  of  business  systems  and 
Commercial  Off  The  Shelf  (COTS)  products  were  the  primary  concern.  Four  internal  inventory 
programs  were  cited  as  needing  repair.  They  are: 

Ready  Issue, 
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Tool  Control, 

AIC  Lab  Worklog,  and 
Requisition  Tracking. 

They  were  locally  developed  and  can  be  corrected  within  a  month.  Further  investigation  is 
ongoing. 

Mr.  John  Dawson  (5/14/96L 

Mr.  Dawson  is  responsible  for  all  electromagnetic  effects  laboratories  at  NAWCAD,  Patuxent 
River.  He  was  generally  aware  of  the  Year  2000  problem.  He  felt  there  was  no  perceived  effect 
on  his  operation.  He  did  survey  his  people.  The  largest  threat  is  from  desktop  computers  and  they 
will  all  be  replaced  by  2000.  His  systems  deal  heavily  in  time,  but  do  not  involve  date 
calculations.  He  acknowledged  that  Operating  Systems  should  be  examined  in  his  older  data 
systems.  He  felt  his  Halon  removal  program  was  a  greater  Year  2000  issue.  It  must  be  replaced 
by  then  by  regulation  and  there  are  no  funds  allocated  for  its  removal  and  replacement. 

Mr.  Rav  Nowak  (5/19/961. 

Mr.  Nowak  is  responsible  for  large  scale  Models  and  Simulations  (M&S)  and  their  design  and 
conduct  at  NAWCAD,  Patuxent  River.  These  systems  range  from  Force-on-Force  combat 
engagements  to  single  system  performance.  He  is  deeply  involved  in  state-of-the-art  growth  via 
High  Performance  Computing.  Growth  has  been  astronomical  since  the  advent  of  the 
Competency  Aligned  Organization  (CAO)  realignment.  He  was  generally  aware  of  the  Year 
2000  problem.  In  the  main,  he  felt  he  had  little  problem.  He  uses  state-of-the-art  SGI  equipment 
which,  if  not  already  Year  2000  compliant,  will  be  made  so  by  the  OEM  who  is  prompt  about 
maintaining  state-of-the-art  integrity  in  this  facility.  M&S  is  time,  but  not  date  dependent.  He 
did  identify  some  areas  worthy  of  further  investigation.  He  had  one  older  lab  that  used  Encore 
gear  (formerly  Gould)  that  may  be  susceptible.  He  was  involved  in  some  C4I  systems  and 
associated  data  links  that  he  felt  required  further  scrutiny  for  date  sensitivity.  He  was  unsure  of 
GPS  and  IRIG  time  based  inputs  and  their  effect,  but  suspected  they  would  be  minimal.  He 
volunteered  a  report  back  in  a  week. 

Mr.  Bill  Rvmer  (Email  exchanges  in  early  April) 

Mr.  Rymer  heads  the  Telemetry  operation  at  NAWCAD,  Patuxent  River,  including  the  Real 
Time  Telemetry  Processing  System  (RTPS).  He  was  initially  unaware  of  the  Year  2000  issue. 
He  had  a  survey  conducted  of  his  operations  for  Year  2000  susceptibility.  No  significant  threats 
were  uncovered.  Some  minor  operating  system  irregularities  were  reported.  He  felt  the  remedy 
responsibilities  largely  fell  upon  his  vendors. 

Mr.  Steve  Whetstone  (5/15/96). 


Mr.  Whetstone  was  referred  to  the  team  by  Mr.  Jimmy  Fairfax  of  Metrology.  Mr.  Whetstone 
heads  the  Laboratory  Instruments  and  Standards  Branch  for  Airborne  Aircraft  Instrumentation. 
This  laboratory  is  responsible  for  calibrating  test  equipment  used  aboard  aircraft,  ships  and  in 
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other  laboratories  in  the  fleet,  at  ranges  and  other  DoD  activities.  He  was  generally  aware  of  the 
Year  2000  problem  but  did  not  foresee  an  impact  on  the  work  done  in  his  lab.  He  stated  that 
although  no  dates  are  used  in  doing  the  actual  calibration  work  he  would  examine  the 
computers  for  Year  2000  compliance  and  report  the  findings  back  to  the  team. 

Subsequently,  Mr.  Whetstone  reported  that  two  types  of  laboratory  computers  are  being  used  for 
calibrations  of  test  equipment  -  -  -  Hewlett  Packard  (HP)  and  Fluke.  The  HPs  support  dates  to 
the  year  2080;  however,  the  Flukes  are  not  Year  2000  compliant  at  all  and  will  only  operate 
when  dates  before  2000  are  entered.  Mr.  Whetstone  stated  that  the  Flukes  are  used  in  10%  - 15% 
of  the  work,  the  HPs  in  50%.  Computers  are  not  used  in  the  remaining  35%  of  the  work.  The 
Fluke  OEM  will  not  support  upgrades  to  alleviate  the  operating  system  Year  2000  flaw; 
however,  Mr.  Whetstone  states  that  both  the  HPs  and  the  Flukes  are  being  phased  out  well 
before  2000  and  their  replacement(s)  will  be  Year  2000  compliant. 

Mr.  Dan  Dickev  (5/15/961. 

Mr.  Dickey  is  head  of  Strike  Missions  System  Branch.  He  was  generally  aware  of  the  Year  2000 
problem  but  perceived  no  impact  on  his  operation.  His  department  uses  Macintosh,  personal 
computers  (PC),  and  an  HP  UNIX  for  project  work  .  He  offered  to  have  systems  checked  for 
Y2000  compliance  and  report  the  findings  back  to  the  Team. 

Upon  setting  the  computer  systems’  clocks  to  a  Year  2000  date,  tests  were  conducted  on  the 
Macintosh  and  PC  types  of  computers.  As  expected,  the  Macintosh  systems  exhibited  no  Year 
2000  anomalies  as  they  are  known  to  be  Year  2000  compliant.  The  one  PC  checked,  a 
COMP  AC,  appeared  to  accept  the  Year  2000  date  when  the  MS  DOS  date  parameter  was  set.  It 
responded  normally  when  project  applications  were  run.  However,  when  the  application  created 
a  file,  the  computer’s  File  Manager  saved  that  file  with  an  erroneous  and  unrecognizable  date, 
i.e.,  l/l/:0.  This  signifies  that  the  computer  software  has  Year  2000  problems. 

Generally,  Mr.  Dickey’s  staff  is  of  the  opinion  that  the  current  software  running  on  desktops  - 
functional  applications,  COTS  office  applications,  and  operating  systems  -  will  not  be  running  at 
the  turn  of  the  century.  They  felt  that  the  hardware  platforms  won’t  be  around  either  and  that 
replacement  systems  will  be  Year  2000-ready.  See  Note. 

Note:  These  test  results  are  typical  of  most  PCs  tested  at  this  site.  It  is  pointed  out,  however, 
that  the  problem  isn’t  completely  pervasive  or  all-inclusive.  Late  model  PCs  do  not  exhibit  Year 
2000  problems.  Their  Basic  Input  Output  System  (BIOS)  chip  has  been  upgraded  for  Year 
2000. 

Mr.  Mike  Hardman  (4/10/961 


Mr.  Hardman  is  the  senior  electronics  technician  responsible  for  development  and  maintenance 
of  the  Multiple  Target  Instrumentation  Radar  (MIR)  at  Chesapeake  Test  Range.  He  was  aware 
of  the  Year  2000  problem  and  his  first  impression  was  that  this  would  not  affect  the  MIR’s 
operation.  A  complete  inventory  of  computer  hardware/software  for  the  radar  was  not  available. 
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He  agreed  to  run  Year  2000  date  tests  on  the  radar’s  computer  (a  Harris  Corp.  H1000-2C  super 
mini)  and  software  applications. 

Preliminary  tests  revealed  that  the  radar  computer  operating  system  (HV OS)  would  not  accept 
Year  2000  dates,  refusing  to  boot  up.  Inquiries  to  the  manufacturer  (Harris  Corp.)  revealed  that 
they  were  not  aware  of  this  problem.  Harris  is  investigating  whether  newer  versions  of  the 
operating  system  (current  version  is  8  years  old)  are  compliant.  The  radar’s  application  programs 
do  not  use  any  date  information  so  are  unaffected.  The  impact  is  considered  minor  since  the 
problem  will  not  down  the  radar  system  or  cause  any  operational  problems. 

Mr.  Henrv  Shune  (5/15/96) 

Mr.  Shupe  is  a  computer  scientist  responsible  for  development  and  maintenance  of  three  Vitro 
RIR-778  radar  systems  at  Chesapeake  Test  Range.  He  was  not  aware  of  the  Year  2000  problem. 
A  complete  inventory  of  computer  hardware/software  for  the  radar  was  not  available.  He  did  not 
know  if  his  systems  would  be  impacted  but  agreed  to  run  simple  Year  2000  date  tests. 

Preliminary  test  results  revealed  that  the  radar  software/hardware  are  Year  2000  compliant. 
New  radar  computers  are  expected  to  be  installed  prior  to  the  Year  2000  and  they  will  be 
specified  to  be  Year  2000  compliant. 

Mr.  Bruce  Bumsed  (5/30/96) 


Mr.  Bumsed  is  a  senior  computer  scientist  for  Vitro  Corp.  and  is  responsible  for  development 
and  maintenance  of  range  radar  systems  through  the  Instrumentation  Radar  Support  Program 
(IRSP).  The  IRSP  supports  the  Navy,  Army,  Air  Force,  NASA,  DOE,  and  U.K.  test  and 
evaluation  ranges.  He  was  aware  of  the  Year  2000  problem  but  had  not  taken  any  action  to 
respond  to  the  problem.  His  first  impression  was  that  this  was  not  a  problem  which  would 
impact  range  radar  systems.  He  said  he  needs  to  conduct  tests  and  investigations  to  determine 
any  impact.  No  results  have  been  reported  to  the  team  to  date. 

Mr,  Sam  Schrader  (5/16/96) 

Mr.  Schrader  is  responsible  for  the  Passcard  security  systems  at  Chesapeake  Test  Range.  The 
Passcard  security  systems  control  access  to  the  facility.  He  was  not  aware  to  the  Year  2000 
problem.  A  complete  inventory  of  computer  hardware/software  for  the  Passcard  security  systems 
was  not  available.  He  did  not  see  any  impact  that  Year  2000  would  have  on  the  Passcard 
security  system  but  could  not  say  for  certain. 

Mr.  Dick  Stepanian  (4/30/96) 

Mr.  Stepanian  is  responsible  for  computer/software  configuration  management  at  the  U.S.A.F.’s 
30th  Space  Wing  at  Vandenburg  AFB.  He  was  aware  of  the  Year  2000  problem.  He  stated  that 
this  was  not  an  issue  at  their  range  because  of  a  planned  replacement  of  all  range 
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systems/equipments  under  the  RSA  (Range  Standard  Architect)  program.  This  program  is 
scheduled  to  be  completed  prior  to  2000. 

Mr.  Ken  Clarke  (  5/29/961 

Mr.  Clarke  is  Program  Manager  for  the  GPS  office  at  Chesapeake  Test  Range.  He  was  aware  of 
the  Year  2000  problem.  A  complete  inventory  of  computer  hardware/software  for  the  GPS 
systems  was  not  available.  He  stated  that  the  only  date  information  used  in  GPS  systems  was 
IRIG  based  and  that  this  utilized  the  Julian  date  format.  He  felt  that  the  Year  2000  problem 
would  not  have  any  impact.  (However,  see  Joe  Gwinn  message  below.) 

Mr.  Tony  Winkleman  16/18/96) 

Mr.  Winkleman  is  Program  Manager  for  the  Real  Time  Dynamic  Radar  Cross  Section  (RCS) 
Test  Facility  at  Chesapeake  Test  Range.  Mr.  Winlkeman  advised  the  team  that  Y2000  tests  he 
performed  on  the  radar  controller  computer  (Motorola  Unix  Version  3.5.1)  demonstrated  that  it 
will  not  except  dates  beyond  1999  on  input.  Attempts  to  enter  any  year  in  the  two  digit  year 
field  between  00  and  69  are  reset  to  70.  However,  the  system  appeared  to  successfully 
“rollover”  to  2000  when  the  system  date  was  advanced  to  12/31/99.  Subsequently,  new  files 
where  apparently  correctly  dated  with  Year  2000  creation  dates.  Regardless,  the  inability  to 
input  correct  dates  would  be  detrimental  to  the  operation  of  Mr.  Winlkeman’ s  function.  He 
anticipates  this  machine  will  be  replaced  before  2000. 

Mr.  Joe  Gwinn  (6/26/96) 


Mr.  Gwinn  is  an  engineer  at  Raytheon.  The  information  below  was  provided  by  him  via  email  to 
interested  parties  and  was  not  obtained  by  Year-2000  Team  interviewers.  His  message  is 
included  here  with  his  permission. 

Subject:  The  Millennium  comes  early  to  GPS 

I  have  good  news  and  I  have  bad  news. 

The  good  news  is  that  GPS  will  not  have  a  "Year  2000"  problem. 

The  bad  news  is  that  GPS  System  Time  will  roll  over  at  midnight  21-22  August  1999,  132  days 
before  the  turn  of  the  millennium.  On  22  August  1999,  unless  repaired,  many  or  all  GPS 
receivers  will  claim  that  it  is  6  January  1980,  23  August  will  become  7  January,  and  so  on.  I 
would  expect  that  some  manufacturers  have  already  solved  the  problem,  but  many  have  not. 

The  details:  Section  3.3.4(b)  (page  33)  of  the  ICD-GPS-200  rev  B  (30  November  1987  issue) 
states  that  the  GPS  Week  count  starts  at  midnight  5-6  January  1980  UTC,  and  that  the  GPS 
Week  field  is  modulo  1024.  This  means  that  the  week  count  will  roll  over  1024/52  =  19.69  years 
from  then,  or  in  1980  +  19.7=  1999.7  (August  1999),  only  a  few  years  from  now. 
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For  the  record,  this  is  how  the  precise  rollover  date  was  computed:  The  origin  (time  zero)  of 
GPS  System  Time,  00:00:00  UTC  6  January  1980,  is  Julian  Day  2,444,244.500.  A  GPS  Cycle  is 
1,024  weeks,  or  7,168  days,  so  the  first  GPS  rollover  will  occur  at  Julian  Day  (2444244.5+7168) 
=  2,451,412.5,  which  is  00:00:00  UTC  22  August  1999  AD,  which  is  the  midnight  between 
Saturday  night  the  21st  of  August,  and  Sunday  morning  the  22nd  of  August,  1999. 

I  could  find  no  mention  of  any  field  in  any  GPS  message  that  would  tell  you  which  1024-week 
cycle  you  were  in.  In  the  July  1993  update  of  ICD-GPS-200,  a  note  has  been  added  (also  on 
page  33)  saying  that  the  week  number  *will*  roll  over,  and  that  users  must  account  for  this,  but 
no  way  to  accomplish  this  is  mentioned.  I  take  this  note  as  further  evidence  that  there  is  no  way 
to  tell,  given  only  the  signal-in-space  definition  as  of  July  1993.  (I  have  been  unable  to  find  ICD- 
GPS-200  on  the  web.  I  am  told  it  may  be  obtained  from  the  GPS  Program  Office,  in  the  US  Air 
Force.) 

I  now  have  found  a  more  recent  authority  document  to  reference.  The  GPS  SPS  Signal 
Specification,  2nd  Edition,  issued  on  2  June  1995,  repeats  the  words  and  warnings  of  ICD-GPS- 
200.  The  GPS  SPS  Signal  Spec  does  cover  the  bulk  of  what's  in  ICD-GPS-200,  and  covers  the 
rollover  problem  exactly  as  well  as  does  ICD-GPS-200.  The  GPS  SPS  Signal  Specification  may 
be  obtained  from  the  web  as  an  Adobe  Acrobat  (.pdf)  document,  at 
"www.navcen.uscg.mil/gps/reports/sigspec/sigspec.htm". 

I  have  posted  notices  to  a  number  of  relevant  newsgroups  (NTP,  GPS,  and  Risks).  So  far, 
nobody  has  even  claimed  that  rollover  won't  happen,  let  alone  provided  a  convincing  argument. 
I  did  get  one  now-explained  then-inexplicable  war  story,  and  a  number  of  questions,  and  a  few 
thank-you  notes.  But,  it's  been  a  lot  quieter  than  I  would  have  thought.  I  think  that  many  more 
people  care  about  navigation  accuracy  (unaffected)  than  time  accuracy  (sometimes  severely 
affected).  And,  not  that  many  people  read  such  arcane  newsgroups. 

A  fellow  at  DEC,  reacting  to  my  postings,  suggested  that  one  can  use  the  offset  between  UTC 
and  GPS,  currently  eleven  seconds  and  increasing  more-or-less  linearly,  as  a  way  to  tell  which 
1024-week  cycle  you  are  in,  at  least  for  the  next  few  cycles.  I  have  looked  into  this,  and  it  does 
appear  to  be  workable,  if  rough.  If  one  bums  both  the  date  of  manufacture  and  the  then-current 
value  of  the  GPS-UTC  offset  into  the  firmware,  it  should  allow  the  firmware  to  solve  the  rollover 
problem  for  at  least  three  GPS  cycles,  almost  60  years,  which  should  suffice.  The  leap-second 
story  is  at"http://tycho.usno.navy .miPleapsec.html". 

I  have  gotten  some  email  traffic  indicating  that,  just  as  I  had  suspected,  some  manufacturers  did 
realize  that  GPS  would  soon  roll  over,  and  were  keeping  it  to  themselves  in  the  hope  that  the 
others  would  fall  upon  their  swords.  I  have  subsequently  found  more  indications  that  some 
manufacturers  know,  but  are  keeping  it  to  themselves.  One  claims  to  have  a  solution,  the  details 
of  which  are  proprietary.  Not  pretty. 

Our  supplier  was  dumbfounded  when  I  raised  the  issue,  couldn't  stop  thanking  me  for  pointing  it 
out  years  before  rollover.  They  clearly  feel  that  it  could  have  been  a  life-threatening  disaster  for 
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them.  Every  GPS-related  product  they  had  ever  made  would  have  come  back  for  repair,  many 
under  warantee,  all  at  once.  Too  close  for  comfort.  And,  discovered  by  luck. 

The  firmware  in  all  affected  (older)  units  will  have  to  be  replaced.  This  will  involve  replacement 
of  PROMs;  some  are  socketed,  some  are  soldered.  New  units  presumably  will  know  better  than 
to  claim  dates  from  before  they  were  manufactured,  and/or  will  allow  the  user  to  directly  or 
indirectly  tell  the  firmware  which  1024-week  cycle  to  assume,  without  requiring  replacement  of 
that  firmware  at  the  second  rollover,  in  1980  +  (2*1024/52)  =  2019  AD.  Some  of  this  equipment 
will  still  be  in  use  then,  long  after  the  manufacturer  has  forgotten  the  product,  or  has  himself 
been  forgotten.  Nor  is  it  guaranteed  that  the  needed  PROMs  will  still  be  available. 

However,  in  spite  of  everything,  not  everybody  will  get  the  message,  so  system  software  will 
forever  have  to  have  an  independent  idea  of  what  year  it  is,  to  know  when  to  disbelieve  a  receiver 
or  receivers  (they  could  all  be  wrong),  and  to  handle  arguments  between  various  GPS  receivers 
(if  only  some  are  wrong). 

Without  a  GPS  Simulator,  there  is  no  way  for  users  to  test  a  GPS  receiver  for  this  problem.  All 
most  users  can  do  is  to  ask  their  manufacturer  for  a  solution,  and  also  to  imbue  the  system 
software  with  a  suitable  degree  of  skepticism  about  GPS  receivers'  sense  of  time. 

My  intent  in  posting  this  note  is  to  alert  the  entire  industry  to  the  problem,  allowing  it  to  be 
solved  with  minimal  disruption  to  all.  As  a  technical  matter,  the  solution  is  quite  simple.  It's  the 
logistics  that  will  take  some  years. 


AIR  FORCE  FLIGHT  TEST  CENTER  (AFFTCV  EDWARDS  AFB,  CALIFORNIA 

Interview  Results 

Informal  interviews/discussions  concerning  the  potential  impact  of  the  Year  2000  (Y2K) 
problem  were  held  with  key  personnel  located  in  the  business,  infrastructure,  range  and 
engineering  areas  at  the  AFFTC.  In  general,  those  interviewed  were  aware  of  the  Y2K  problem. 
In  addition  a  total  of  131  systems  were  reviewed  and  broken  down  into  the  following  categories: 

Locally  Developed  Business  Systems 
PC  Systems/ Applications 
Engineering/Range  Systems 
Comm/Computer  Infrastructure 

A  synopsis  of  the  interviews  by  functional  area  follows: 

Locally  Developed  Business  Systems 

Ms.  Julie  Karr 
Capt.  David  Winters 
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Mr.  Carl  Pee 


The  major  Center  wide  business  systems  that  are  expected  to  continue  beyond  2000  are  believed 
to  be  century  aware  and  will  not  suffer  significant  failures.  All  of  these  systems  have  been 
developed  within  the  last  10  years  with  significant  hardware/software  upgrades  occurring  within 
the  last  two  years.  The  systems  employ  platforms  (DEC  Alpha),  operating  systems  (UNIX)  and 
software  (Oracle,  Sybase)  that  are  reportedly  Y2K  compliant.  Initial  programmers  and  those 
doing  follow-on  maintenance/upgrades  are  generally  Y2K  aware.  The  overall  feeling  is  that  very 
minor  problems,  if  any,  will  occur  after  the  Y2K  change. 

PC  Systems/Applications 

Mr.  Pete  VonKlargaard 
Mr.  Don  Knight 
Mr.  Bruce  Berger 

It  was  generally  felt  that  the  PCs  currently  being  used  across  the  Center  would  have  a  minor,  if 
any  impact  at  all.  The  majority  of  the  systems  being  used  are  expected  to  be  replaced  prior  to  the 
Year  2000  and  those  that  may  remain  in  service  are  felt  to  be  century  aware.  Some  applications 
currently  in  use  have  been  identified  as  having  date  problems  (DB  II,  DB  III,  Access).  However 
it  is  anticipated  that  these  applications  will  be  replaced  or  upgraded  prior  to  the  Year  2000. 

Engineering/Range  Systems 

Dr.  Henry  Bunch 
Mr.  Mike  Hughes 

The  primary  engineering/range  support  systems  have  been  replaced/upgraded  over  the  last  two 
years.  It  was  felt  that  the  hardware/software/operating  systems  currently  being  used  are  century 
aware  and  will  not  suffer  significant  problems.  Other  range  instruments  such  as  radar  systems, 
cine-t’s,  etc.,  are  also  planned  for  upgrade,  replacement  or  mothballed  prior  to  the  Year  2000. 
The  overall  feeling  was  that  the  Y2K  will  only  bring  a  minor  impact  to  the  range/engineering 
systems. 

Comm/Computer  System  Infrastructure 

Mr.  Pete  VonKlargaard 
Mr.  Bruce  Berger 

Some  concern  about  the  impact  of  Y2K  on  the  overall  infrastructure  was  expressed,  however,  no 
specific  problems  were  identified.  A  new  telephone  switch  is  currently  being  installed  that  the 
vendor  claims  is  Y2K  compliant.  Studies,  such  as  Mitre,  have  reported  suspected  problems  with 
telephone  switches  but  confirmation  of  such  as  not  been  shown.  Further  research  is  being  done 
to  determine  if  a  problem  exists.  The  impact  on  Y2K  on  the  network  infrastructure  is  also 
unknown.  The  network  consists  of  numerous  routers,  gateways,  etc.,  that  all  could  be  subject  to 
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some  level  of  failure.  However,  no  vendors  or  studies  have  identified  specific  problems. 
Testing  methodologies  also  seem  to  be  non-existent  for  many  of  these  components. 

Other  Concerns 

Air  Force  Standard  Systems  -  Numerous  AFFTC  functions  are  dependent  upon  Air  Force 
Standard  Systems.  The  impact  of  Y2K  on  these  systems  is  unknown  at  the  present  and  cannot  be 
locally  determined.  These  systems  are  developed  and  maintained  by  the  Standard  System 
Center  (SSC)  at  Gunter  AFS,  AL.  The  SSC  is  evaluating  these  systems  for  Y2K  impact. 

Embedded  Systems  -  The  impact  of  the  Y2K  on  systems  embedded  within  aircraft  could  not 
generally  be  determined  at  the  local  level.  Embedded  systems  will  be  evaluated  by  the  specific 
Major  Commands,  Special  Project  Offices. 


ABERDEEN  TEST  CENTER.  ABERDEEN.  MARYLAND  ,  and 

TEST  AND  EVALUATION  COMMAND.  ABERDEEN.  MARYLAND 
Ms.  Eileen  Viars  (4/24) 


Ms.  Viars  is  the  Senior  Computer  Specialist  for  the  Computer  Operations  Division  at  Aberdeen 
Test  Center  (ATC).  Her  division  is  responsible  for  the  collection,  processing  and  reporting  of 
test  data  for  all  test  and  evaluation  decision  makers.  Her  division  is  aware  of  the  Y2K  problem. 
She  is  responsible  for  running  the  HP  9000/3000  minicomputers  and  the  local  area  network 
(LAN)  .  Her  department  is  waiting  Year  2000  software  patches  from  Hewlett  Packard.  Other 
software  developed  in-house  will  be  modified  there.  The  greatest  impact  will  be  from  systems 
external  to  ATC,  i.e.,  Cost  Accounting,  Test  Resource  Management  System  (TRMS)  and  the 
Defense  Finance  &  Accounting  Service  (DFAS).  She  estimates  the  cost  to  become  Y2K  ready 
will  be  $3,000. 

Mr.  Steven  Hawbecker  (5/3) 


Mr.  Hawbecker  is  a  Mechanical  Engineer  for  the  Physical  Test  Division  at  ATC.  His  division  is 
responsible  for  conducting  testing  on  toxic  fumes  data  acquisition,  alternative  fire  suppressants 
and  refrigerants  and  chemical  analysis.  They  are  aware  of  the  Y2K  problem.  They  feel  that 
there  will  be  a  minor  impact,  all  test  data  does  not  have  date/time  fields  in  it.  The  only  problem 
would  be  in  the  incorrect  date  on  the  hardcopy  printouts.  They  are  assessing  off-the-shelf  and 
locally  written  data  reduction  software  for  impact  and  realize  that  all  PC's  will  need  to  upgrade 
the  BIOS.  His  department  is  checking  with  the  workstation  manufacturers  (SDN  and  Silicon 
Graphics)  to  determine  if  the  problem  exists  and  if  these  OEMs  are  preparing  a  solution.  They 
estimate  a  cost  of  $1,000  to  become  Y2K  ready. 
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Mr.  Dave  Jennings  T5/14) 


Mr.  Jennings  is  Chief,  Optical  Engineering  Division  for  ATC.  His  division  provides  visual 
documentation  of  RDT&E  testing  to  include  ballistic,  automotive  and  live  fire  testing  of  Army 
materiel.  He  is  aware  of  the  Y2K  problem  and  a  minor  impact  is  anticipated.  Date/time  fields 
are  not  a  critical  element  in  operating  camera  systems.  They  have  PC's  and  commercial  software 
which  will  be  updated  by  the  manufacturer.  They  do  not  estimate  any  costs  will  be  incurred  for 
Year  2000  corrections. 

Mr.  John  Gerdes  (5/14") 

Mr.  Gerdes  is  an  engineer  in  the  Radiation  &  Simulation  Directorate  of  ATC.  This  directorate  is 
responsible  for  monitoring  X-rays,  health  physics,  customer  data  acquisition,  and  systems 
analysis.  They  are  aware  of  the  Year  2000  problem  and  have  done  their  own  analysis.  All  old 
PC  controllers  (BIOS)  will  be  upgraded.  Most  computers  will  be  replaced  with  new  models 
before  2000.  Software  fixes  will  be  prepared  for  laboratory  programs.  They  have  estimated  a 
cost  of  $200-$300K  and  six  man-months  of  effort. 

Mr.  Bill  Burch  (5/14! 

Mr.  Burch  is  an  environmentalist  in  the  Environmental  Office  of  ATC.  His  department  is  aware 
of  the  Y2K  problem.  His  office  tracks  hazardous  waste  materials  and  all  such  information  is 
stored  in  a  database  of  the  Hazardous  Waste  Tracking  System.  This  system  resides  on  a 
minicomputer  maintained  by  the  Directorate  of  Information  Management  (DOIM).  DOIM 
interfaces  with  the  DoD  Environmental  Network  Information  Exchange  (DENIX)  in  Washington 
DC.  His  opinion  is  that  there  will  be  little  or  no  impact  to  his  operation  due  to  the  Year  2000 
transition. 

Ms.  Rebecca  Jov  C5/2) 


Ms.  Joy  is  an  engineer  in  the  Technology  Directorate  of  ATC.  Their  main  function  is  to  track 
multi-spectral  signature  measurements  of  military  targets.  All  data  is  housed  in  a  Unix  based 
minicomputer  running  Oracle.  This  office  interfaces  with  the  National  Ground  Intelligence 
Center  (NGIC)  which  has  developed  a  system  that  is  linked  over  a  network  with  twelve  other 
sites.  They  are  investigating  the  availability  of  Year  2000  training  necessary  for  one  of  their 
employees  to  make  modifications  to  their  in-house  programs.  They  estimate  costs  of  $5K. 

Mr.  Tom  Lockard  (16  May) 

Mr.  Lockard  is  the  Chief,  Computer  Operations  for  the  Directorate  of  Information  Management 
(DOIM).  The  DOIM  supports  the  T&E  Command  (TECOM)  for  ongoing  system/program 
maintenance  and  production  execution  of  the  Test  &  Evaluation  Analysis  Management- 
Uniformity  Plan  (TEAM-UP).  One  of  these  systems  is  the  Test  Resource  Management  System 
(TRMS)  which  is  the  primary  information  management  tool  for  TECOM's  testing  mission.  They 
are  aware  of  the  Y2K  problem.  This  office  maintains  and  supports  the  IBM  mainframe  and 


Cll 


minicomputer  systems  for  57  tenants  at  APG  and  the  TECOM  Test  Centers.  The  department 
uses  COBOL  on  its  mainframe,  but  runs  Oracle  and  Informix  on  its  minis.  The  DOIM  is 
forming  a  team  to  assess  the  magnitude  of  the  Year  2000  problem.  They  have  already  started 
talking  to  vendors.  A  cost  analysis  of  $6M  was  calculated  based  upon  rough  estimates  of  the 
number  of  lines  of  COBOL  code  and  industry  projections  for  cost  per  line. 

************ ******* *********************************************************** 
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APPENDIX  D: 


TESTING  YOUR  DESKTOP  FOR  YEAR  2000  COMPLIANCE 
For  MACs: 

A.  From  the  Control  Panel  select  “Setting  Date  And  Time”. 

B.  Using  the  up/down  arrows: 

1) .  Set  the  date  to  12/31/99. 

2) .  Set  the  time  to  11/59/01  (minutes  and  seconds  are  arbitrary). 

C.  Select  OK  or  CLOSE  the  dialog  box. 

D.  Select  “Setting  Date  And  Time”  again. 

E.  The  date  should  be  at  12/31/99  and  the  time  should  be  advancing. 

F.  Wait  until  the  date  changes  (should  roll  over  to  01/01/00). 

G.  Time  should  be  advancing. 

H.  Close  the  dialog  box. 

I.  Create  and  save  a  file. 

1)  Select  the  Apple  icon  from  the  menu  bar. 

2)  Select  the  file  type  (ex:  Microsoft  Word)  from  pull  down  menu. 

3)  Select  File  from  the  menu  bar. 

4)  Select  New  from  the  pull  down  menu. 

5)  Select  the  desired  Template  (ex:  Normal). 

6)  Enter  anything  into  test  file. 

7)  Select  File  from  menu  bar. 

8)  Select  Save  or  Save  As  from  pull  down  menu  (save  to  your  Desktop). 

9)  Enter  the  document  (file)  name  (ex:  testy2k.doc). 

10)  Select  Save. 

J.  Select  File  from  the  menu  bar. 

K.  Select  Quit  from  the  pull  down  menu. 
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L.  Highlight  the  file  you  created  from  the  Desktop. 

M.  Select  File  from  the  menu  bar. 

N.  Select  Get  Info  from  the  pull  down  menu. 

O.  Verify  that  the  file  create  date  is  Jan  1, 2000. 

P.  If  the  file  create  date  is  correct  your  MAC  computer  is  Year  2000  compliant .  If  the  create  date  is 
not  correct  your  MAC  is  not  compliant. 

Q.  Delete  the  test  file  (drag  the  file  icon  to  Trash  can). 

R.  Reset  the  date  and  time  to  today’s  date  and  the  correct  time. 
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For  PCs: 


A.  From  your  Program  Manager  Desktop  menu  select  Main. 

B.  From  Main  select  Control  Panel. 

C.  From  the  Control  Panel  select  Date/Time. 

D.  Using  the  up/down  arrows: 

1)  Set  the  date  to  12/31/99. 

2)  Set  the  time  to  11/59/01  (minutes  and  seconds  are  arbitrary) 

E.  Close  the  dialog  box. 

F.  Select  the  Date/Time  icon  again. 

G.  The  date  should  be  12/31/99  and  the  time  should  be  advancing. 

H.  Wait  until  the  date  changes  (should  roll  over  to  1/1/00). 

I.  If  the  date  doesn’t  change  correctly  your  PC  isn’t  year  2000  compliant.  You  can  set  the  date  to 
1/1/00  and  continue  test  at  Step  K  if  desired,  but  date  will  fail. 

J.  If  the  date  is  correct  continue  test. 

K.  Close  Date/Time  dialog  box. 

L.  Close  Control  Panel  and  Main.  You  should  be  at  Program  Manager  Desktop. 

M.  Create  and  save  a  file  (select  Microsoft  Word,  for  example). 

1)  Enter  anything  into  the  test  file. 

2)  Select  File  from  the  menu  bar. 

3)  Select  Save  As  from  the  pull  down  menu. 

4)  Enter  the  File  Name  in  the  highlighted  blue  box  (ex:  y2ktest.doc). 

5)  Select  a  Directory  to  store  the  file. 

6)  Select  OK  (double  click  on  the  OK). 

N.  Select  File  from  the  menu  bar. 

O.  Select  Close  from  the  pull  down  menu. 

P.  Exit  Microsoft  Word  (for  example). 

Q.  Select  File  Manager  from  menu  bar. 

R.  Select  Directory  where  the  file  was  stored. 
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S.  Select  View  from  the  menu  bar. 


T.  Select  All  File  Details  from  the  pull  down  menu. 

U.  Highlight  the  file  you  created. 

V.  Verify  the  date  the  file  was  created  is  correct  (0/1/00).  If  incorrect  (l/l/:0  for  example)  your  PC 
is  not  Year  2000  compliant. 

W.  Delete  the  test  file  (select  File,  select  Delete  from  the  pull  down  menu,  select  YES  from  the  next 
three  dialog  boxes). 

X.  Exit  File  Manager. 

Y.  Reset  date  and  time. 


The  Reason: 

The  standard  PC  computer  system  maintains  two  system  dates;  one  is  in  the  CMOS  Real  Time  Clock  chip  -  a 
hardware  component  that  is  normally  on  the  machine’s  motherboard  -  and  one  is  in  the  DOS  (and  Windows) 
operating  system  software.  These  two  dates  are  represented  differently.  The  CMOS  RTC  date  is  kept  as 
century/two-digit-year/month/day  and  the  DOS  date  is  kept  as  days-since-1980/01/01  which  is  converted  to 
four-digit-year/month/day  when  any  program  asks  for  it.  When  DOS  boots,  it  normally  initializes  its  current 
date  by  reading  the  date  in  the  CMOS  RTC  and  converting  it  to  days-since-1980/01/01.  DOS  maintains  its 
date  as  long  as  the  system  is  running;  the  CMOS  RTC  hardware  maintains  its  date  whether  the  system  is 
running  or  not,  but  it  does  not  maintain  the  century.  In  the  CMOS  RTC,  year  99  overflows  to  00  and  the 
century  remains  unchanged  so  the  effective  year  becomes  1900;  in  DOS  year  1999  overflows  to  2000.  So 
until  the  system  is  rebooted  there  will  appear  to  be  no  problem  with  the  transition  from  year  1999  to  Year 
2000;  but  trouble  lurks  in  the  CMOS  RTC  date,  which  has  become  year  1900.  When  DOS  boots  it  reads 
1900  as  an  out-of-range  date  from  the  CMOS  RTC  and  the  date  conversion  algorithm  calculates  an 
erroneous  1980-01-04.  That’s  what  the  DOS  date  will  become  after  rebooting  the  system  after  the  Year  2000 
transition  if  the  CMOS  RTC  exhibits  the  standard  flaw. 

Another  Test: 

To  determine  if  your  system  suffers  the  Year  2000  CMOS  RTC  flaw,  from  a  DOS  prompt  set  the  date  and 
time  to: 


Power  off  test: 

C:>DATE  12-31-1999 
C:>TIME  23:59 

Power  off  the  system,  wait  more  than  one  minute, 

Power  on  the  system.  Allow  the  system  to  boot. 

Check  the  DOS  date.  It  should  read  01-01-2000.  If  its  not  (usually  01-04-1980)  your  machine  has 
the  flaw. 

Power  on  test: 

C:>DATE  12-31-1999 
C:>TIME  23:59 
Wait  for  more  than  one  minute. 

Check  that  the  DOS  year  has  changed  to  2000. 
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Reboot.  The  DOS  year  should  still  be  2000.  If  it  does  not  your  machine  has  the  flaw. 


For  a  Year  2000  solution  for  your  PC  refer  to  the  following  WEB  site: 
http://rampages.onramp.net/~gtbecker/ 
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APPENDIX  E: 


Matrix  of  Commercial  Offerings  to  Resolve  Year  2000  Questions 


Locates  application  data  fields; 

MVS  Operating  System,  including 

prepares  detailed  cost  estimate; 

MVS/XA  and  MVS/ESA  supporting 

allows  "what  if’  modeling  for 

products  that  run  in  COBOL,  PL/1, 

assessment  of  different  change 

Assembler,  JCL,  SQL,  DB2,  IMS, 

changes;  menu  driven; 
repeatable, 


verifiable;  impact  analysis. 


Uses  artificial  intelligence  General 
product 


to  find  and  fix  every  Y2K 
problem 


in  software  systems  — 


synthetically.  Core  business 
goal 


is  reengineering  solutions. 


YES  Planning  -  assesses  app  MVS 

portfolio 


Exposure  Id-  detects  date  refs 


Exposure  Solution  -  correct, 
migrate, 


test  a  Year  2000-ready  system. 


Produces  inventory  of 
software, 


checklist  for  Y2000,  Imp  plan. 
Toolkit 


product  allows  conv  &  testing 
apps  in 


piecemeal  fashion.  Conv  data 
files 


YES  I  Impact  Analysis 


El 


Conv  Planning 


Code  Conv  &  Data  Conv 


Testing  &  Implementation 


Expertise  in  change  analysis, 


config  mgmt,  and  testing 
techniques 


CAPGEMINI  AMERICA 


Iselin,  N.J. 


908-906-0400,  Fax  908- 
906-0969 


New  York,  NY 


212-944-6464  ext  232 


Fax  212-944-8760 


Uses  artificial  intelligence  tool 
set. 


Uses  their  Application 
Renovation 


Center  (out  source)  to  leave 
your 


ongoing  operations 
undisturbed. 


y 


tool-supported  outsourcing 
vendor 


who  can  save  money  and 
provide  _ 


high  quality  deliverables. 


Computer  Associates 


One  Computer  Associates 
Plaza 


Islandia,  NY  11788-7000 


516-342-5224 


Pre-packaged  solutions  and 

Source  code,  JCL,  PROCS 

conv  assist  for  Y2K  efforts. 

Database  conv,  documentation, 
MVS,VSE,  PC  Workstations 

S/W  driven  impact  assmnt  on  mainframes/PC  workstations 

i 

Detail  info  on  date  fields 


Inventory,  LOC,  number  and  %  on  date  fields 


Y2K  project  plan,  impact  anal 


imp,  unit  and  system  tests, 


regression  tests,  deploy,  LCM 


Computer  Horizons  Corp. 


Mountain  Lakes,  NJ 


800-321-2421,  Fax  201- 
402-7988 


1  Five  phased  approach  from 


discovery  (assessment)  to 


implementation.  Creates 
application  portfolio, _ 


then  analysis, 


construction,  testing  and 


implementation. 


j  A  service  for  converting 


mainframe  COBOL  applications 


frame  COBOL  applications 


Impact  Analysis 


Conv  Planning 


Code  Conv  &  Data  Conv 
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problems.  Provides  extensive 


costing  &  resource 
requirements 


analysis.  Done  on  an 
application- 


by-application  basis  which  are 


then  rolled  into  a  portfolio 
sizing 


report.  Pilot  project  focus.  800 


million  lines  of  code  evaluated 


since  1991,  over  1  billion 
under 


Decision  Systems 
Technologies,  Inc. 

6301  Ivy  Lane,Suite  600 


Greenbelt,  MD  20770 


301-441-3377 


Fax  301-441-4571 


Currently  Since 
supporting  1986 
IRS 


A  systems  engineering  and 
SAV  engineering  company. 


Unisys  2200,  Sun  SPARC 
Workstations,  486/66  PCs,  Unix 
Lan,  COBOL,  Windows  for 
Workgroups, 


MSO  Open,  Microfocus,  ORACLE, 
SUN  Solaris,  more 


300  professionals.  Focus  is 


systems  development,  exec 


info  systems,  reengineering, 


network  integration  and  mgmt,  Has  several  IDIQ  task  order 
contracts  via  Fed  Agencies 


systems  integration,  info  engineering. Y2k  is  primarily 
consulting, strategy,  planning. 


DBStTAR,  Inc 

1 85  Berry  Street 

San  Francisco,  CA  94107- 

1729 

415-512-0300 
Brian  Boyle 


Tool  examines  actual  data  Analytical  tool  for  data  artifact 
artifacts  vice  code  parseing.  anaysis 
Assesses  for  probable  date  data 
patterns .  Resulting  annotated 
data  maps  can  also  serve  as 
analytical  tools  for 
reengineering  efforts.. 


General  Services 
Administration 


Technical  Services  Div 


7th  &D  Sts.  SW,  Rm  6109 


Washington,  DC  20407 


202-708-7700 


Fax  202-708-7714 


(see  OAO  below) 


Federal  Information  Systems 
Support 


Program  (FISSP).  Provides 
reqmnts 


contracts  to  meet  IT  needs  of 
Fed 


agencies.  Provides  existing 
procrmnt 


vehicles.  Assists  SOW,  issues 
RFP, 


evaluates  proposal,  negotiates 
task 


order,  administers  task.  Has 


precompeted  contracts  for 
Y2K. 


"The  Year  2000  and  2-Digit 
Dates: 
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Quintic  Systems, Inc. 
3166  Des  Plaines  Ave 
Suite  36 
Des  Plaines 

,  ILL  60018 


SEEC,  Inc.  &  CBSI 


"COBOL  Analyst" 


(SEEC)  412-682-4991 


(SEEC)  Fax  412-682-4958 


(CBSI)  810-488-2088 


(CBSI)  Fax  810-488-2089 


Source  Recovery  Company 


992  East  Freeway  Drive 


Conyers,  GA  30207 


770-785-9801 


Fax  770-760-7316 


SYNTEL 


Steve  Brass 


Fax  919-233-4517 


TRANS  Century  Data 
Systems 


"TRANS  Century  Calendar 
Routines" 


Impact  analysis,  Code/File 
Conv,  automatically  expands 
to  a  4  digit  year.  S/W  converts 
multiple  date  formats; 
expands,  contracts  or 
maintains  record  size;  converts 
record  formats;  analyzes  data 
for  date  fields;  adjusts  file  data 
to  simulate 

COBOL, SAS,Assemblr  (BAL), 
PL/1,  Fortran,  4GLs,  MVS, 
VSE/ESA,  TANDEM 

future/past  dates  which  verify  program  accuracy. 

Products  support  the 
estimation  of 


cost  and  effort  to  reengineer 
COBOL  _ 


systems  to  be  Y2K  compliant. 
Will  _ 


train  your  staff  to  make 


Creates  source  code  from 
machine 


SRC  recovers  COBOL, CICS,  DB2, 


IMS,  BMS  MAPS,  Assembler,  any 


MVS/VSE/VM  program 


A  software  Solutions  Services  1IBM  mainframes,  UNISYS 


Company  that  provides  Digital,  UNIX,  C/S 

technical  _ 


people  to  your  site  or  at  their 


labs.  4000  professionals,  time 
&  _ 


mtls,  turn  key  and  project 
service 


Provides  a  reliable  and 


comprehensive  set  of  date  COBOL,  DB2,  etc 
routines  _ _ 


which  support  Y2K  conversion 
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Viasoft,  Inc. 

3 

Determine  scope,  size,  level  of 

MVS  operating  system,  including 

effort.  Identifies  project 
reqmnts 

MVS/XA  and  MVS/ESA  supporting 

Phoenix,  AZ 

and  prepares  work  plan. 
Manages 

products  that  run  in  the  following 

602-952-0050,  Fax  602- 
840-4068 

implementation  and  testing  of 

environments:  COBOL/370;  OS/VS 

http://wwwiviasoft.com 

changes,  i.e.,  plans,  manages, 
and 

COBOL;  ANSI  COBOL;  CASE- 

generated  Cobol;  Cobol  D,  E,  and  F; 

CICS,  DL/1,  IDMS,  and  SQL; 

Workbench 

WANG 

YES 

Impact  Analysis 

703-827-3800 

Conv  Planning 

Fax  703-827-3406 

Code  Conv  &  Data  Conv 

Testing  &  Implementation 

Compiles  a  list  of  business 

processes  from  which 
applications 

and  data  bases  that  support 
each 

process  are  determined. 

Compiled  as  of  5/31/96 

************************************************************************ 
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